Refactor tls configs [1/3]

[Lagovas]

Here is added function for registering flags for tls configs and final construction tls.Config structs. First candidate for use is Redis. This update will help easily register similar flags to generate config with ocsp/crl usage, same wording and naming. Additionally, it allows generate flags for components that works as client or database which represented in naming (as we do now) and extra flags (like SNI for clients).

Why clients may need separate configuration for different components? For example, if they have several cloud solutions with TLS support, with own CA and server's certificates. For example, if service deployed on AWS, uses AWS's database, uses Elastic cloud for search features and cloud managed Hashicorp Vault.

There are left base common flags (tls_key/tls_cert/tls_auth/tls_ca) that works as one-place configuration for all configs that allows to specify only them in the simplest cases.

Also, remove the previously deprecated tls_db_sni parameter that breaks general design of TLS configuration. And much easier to remove it instead of supporting edge-case.

Additionally such configuration extended current client/database parameter separation with separate ocsp/crl parameters.

Checklist

• [ ] Change is covered by automated tests
• [ ] The coding guidelines are followed
• [ ] Public API has proper documentation in the Acra documentation site or has PR on documentation repository with new changes
• [ ] CHANGELOG.md is updated (in case of notable or breaking changes)
• [ ] CHANGELOG_DEV.md is updated
• [ ] Benchmark results are attached (if applicable)
• are up-to-date (in case of API changes)

[Lagovas]

I will re-create PR from branch in this repository to be able to create next PR's with merging into this branch to avoid a lot of duplicated changes. After merging base PR's I will change result branches.