Rework certificate handling to module

Thanks for the very valuable feedback @jpmens and @bodsch !

We have a lot of tasks regarding certificate handling with Elastics own tool for CA and certificate handling. Getting them as stable and idempotent as they are now gave us a really hard time. Especially thanks to @afeefghannam89 for all the energy put into that code.

Maybe the collection could benefit from modules taking care of all the handling. Here are some ideas I caught when talking to the guys mentioned at the top:

• Having one call of a module instead of constantly runnnig multiple tasks will greatly speed up the execution of the roles
• We can have a single task, similar to the ones in community.crypto that receives all specifics of the certificate and we can just check the existing certificates within the module. e.g. passphrase, SANs, names, algorithms, expiry date . If the files fail to satisfy one we can instantly replace them by calling the provided tool on the CA host
• In some cases we could locally store a checksum over a list of parameters and just check whether this checksum is different from that on new runs. Although, with certificates it might be better to check the actual file

Some ideas to consider:

• We have a local copy of all files on the CA host. But what if that get's lost, corrupted, whatever. Do we want to recreate the files and transfer them to the target host even when it doesn't need changes because it still hase the old variant?
• Same goes for checks. We can easily check all and recreate all files on the CA host. But what if files are different on the target host? Should we check with checksums or do the check on the target host in the first place?

Start by reviewing the collection's existing certificate-handling tasks and roles, then compare them with the module patterns in community.crypto. The proposal discusses consolidating repeated tasks, validating passphrases, SANs, names, algorithms, and expiry dates, and handling CA-host and target-host file differences. The issue does not define a final design or completion criteria.