Public API to retrieve cert key and cert chain files written to the fs separately

Usually at high-level web servers expose separate configuration options for a certificate file, a private key file, and a certificate chain file.

Currently trustme forces users to use one file for both certificate file and its key file (as it https://github.com/aio-libs/aiohttp/commit/c180800a4c90dc123d05311edbec92a3a82d6317#diff-3ba621217225120eff2c061666b8043cR284) and use CA cert for chain option.

From the API perspective, it looks confusing to any humble human being who isn't proficient in TLS.

When one looks at such tests they're puzzled: why options named explicitly as key and cert receive the same var? maybe it's a bug? what's going on here?
Same for cert chain: why does it look like instead of some mysterious chain file there's a certificate or the CA?

Proofs:

• https://github.com/cherrypy/cheroot/blob/d31adfe/cheroot/ssl/__init__.py#L24
• https://github.com/cherrypy/cheroot/blob/d31adfe/cheroot/ssl/builtin.py#L91
• https://github.com/cherrypy/cheroot/blob/d31adfe/cheroot/ssl/pyopenssl.py#L241
• https://github.com/cherrypy/cherrypy/blob/e10b984/cherrypy/_cpserver.py#L104-L112
• https://github.com/aio-libs/aiohttp/blob/master/aiohttp/worker.py#L188-L191
• https://github.com/pallets/flask/blob/master/flask/cli.py#L733-L738

I think this use case deserves corresponding public APIs in place. What do you think?

Start by reviewing the current trustme API behavior described in the issue and compare it with the cited integrations in cheroot, CherryPy, aiohttp, and Flask. Define public APIs that expose the certificate, private key, and certificate-chain files separately, then add coverage showing each returned path is suitable for the corresponding server configuration option.