Support OS certificate store for TLS CA root

[max-au]

At the time being, ssl application has no defaults for Root CA store. It is a user responsibility to provide one, downloaded on the side.

Describe the solution you'd like
Most operating systems have root CA stores available. I'd like to add the OS storage as the default for {cacertfile, ...} option of the ssl application.

Additional context
I have been researching this topic in order to make a Pull Request, when @KennethL mentioned that @dgud and @IngelaAndin are also exploring this space.
I'd like to share some findings and synchronise the development in order to avoid overlaps.
My findings and ideas so far:

• centos root CA store is available as /etc/pki/tls/certs/ca-bundle.crt
• ubuntu root CA store is at /etc/ssl/certs/ca-certificates.crt
• freebsd root CA store is at /usr/local/share/certs/ca-root-nss.crt or /etc/ssl/cert.pem if the former does not exist
• windows: native code is required to read the Root CA store, see https://docs.microsoft.com/en-us/windows/win32/seccrypto/example-c-program-certificate-store-operations
• mac OS: technically keychain is available at /System/Library/Keychains/SystemRootCertificates.keychain (plus personal keychain), but official API is Keychain Access (also requiring native code)
• sunos (solaris): /etc/certs/CA

Several more links to take inspiration from:

• https://github.com/rustls/rustls-native-certs
• curl: https://github.com/curl/curl/blob/18480f71be0685ee6becaa85c762c6b7956a2402/acinclude.m4#L2027-L2032
• go: https://go.dev/src/crypto/x509/root_linux.go

I can come up with a draft PR covering Linux + FreeBSD. Tackling Windows and MacOS requires agreement on where to put the native code. My hopes would be to add it to crypto application, to avoid introducing extra NIF build complexity for ssl application. If this approach is acceptable, I would suggest for crypto app to have an API providing required access to the certificate store. Alternative is to export this from public_key app, but it also has no associated NIF.

[dgud]

You are way ahead of me, I have not even started investigating this.
After a short discussion we believe it is best to make it inside public_key, it belongs best there, or maybe
a new application, but start with a new API module in public_key.
In public_key you will need a new configure file but that is easier than changing the current one in crypto anyway.

[dgud]

Something like this?

WIP #5853

[dgud]

Merged #5853 to master