OpenSSL configuration file block merging is not implemented

[t184256]

Preface
A few of the actors analyze the openssl configuration file,
and leapp-repository carries a bare-bones parser for it.
At least opensslenginescheck.py, in its quest for figuring out the effective values,
stops at the first appropriately-named block and takes the value from there.
Unfortunately, that's not how the real openssl parser treats the config file:
the blocks bearing the same name can repeat and the values in the repeated blocks override the values in prior ones.

To Reproduce

1. append a section to an otherwise default /etc/pki/tls/openssl.cnf
   that should get the config flagged for using engines,
   e.g., the following example from openssl-ibmca documentation:

[openssl_init]
engines = engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /usr/lib/ssl/engines/libpkcs11.so
MODULE_PATH = opensc-pkcs11.so
init = 0

2. run leapp preupgrade

Expected behavior
opensslenginescheck.py flags the usage of engines usage and warns the user.

Actual behavior
opensslenginescheck.py does not flag the engines usage
(because it looks at the preceding sections and never even reaches the overridden blocks/values in its traversal).

Additional context
I've tried my hand at implementing the merging as the file is being parsed right in readconf.py
(and turning the model from Lists into StringMaps along the way),
but, as it turns out, there's at least one check that
cares about analyzing the unmerged configuration file representation. So, if this one has to be kept,
such quick fix would not be enough and some deeper architectural re-thinking will be needed, I guess?
Two models, a merged and an unmerged one? Or merging manually before most of the checks as post-processing?
Sounds like something that can be easily forgotten.

cc @Jakuje