Allow users to request database certificates in Machine ID

[timothyb89]

This adds a new destination-level config option to tbot.yaml that allows users to request database access for a particular destination certificate. Behind the scenes, this triggers generates two impersonated certs: the first identity is generated to request the specified roles and resolve the database config, then is replaced with a new identity using those roles plus a fully-formed RouteToDatabase request. We don't match tsh's behavior here as the additional certs generated conceptually similar enough to Machine ID's multiple destinations - if users don't want a cert with RouteToDatabase they can just add another destination with the same roles.

Database requests are made by adding a destination entry like the following to tbot.yaml:

destinations:
  - directory: ./tbot-user

    database:
      service: <teleport database name>
      username: <database username>
      database: <database name>

    # The certs won't be very useful without TLS
    kinds: [tls]

We currently don't support proxying or generating db-specific config files. See #11596 for an identityfile implementation that can help. Additionally, we don't currently have a tsh proxy equivalent so the legacy MySQL handlers need to be enabled, which is not the case by default in Teleport 9. However, that same PR can export a tsh-compatible identity file for the datbase identity which can be passed along to tsh -i ... and presumably used with its proxy commands. We plan to follow-up with another PR to improve this UX.

If using MySQL/MariaDB with the legacy proxy handler exposed, this command should connect to the database:

mariadb -vvvv --ssl-key ./tbot-user/key --ssl-ca tbot-user/tlscacerts-test --ssl-cert ./tbot-user/tlscert  -h <teleport proxy host> --port=3036 --protocol TCP -u <database username> --ssl-verify-server-cert

---

Somewhat unrelatedly, this PR also moves most cert renewal-related code into a new file. It makes for an unpleasant diff, but it needed to happen eventually.

[timothyb89]

While writing the PR description I realized I did still have a manual hack in place for the TLS CA certs. We still use $ as a separator character since we internally need both Teleport's user and host certs, but obviously literally nothing supports this "format". I'm gonna think on the best way around this - we might just not want to write these weird cert types to destination dirs since the bot doesn't even use them, and separately write sensible CA certs.

[zmb3]

The godoc is incomplete here. What is service supposed to be?

[timothyb89]

After thinking on it I think I'd like to resolve the missing TLS CAs as part of #11596 where we'll be making significant changes to artifact saving/loading anyway. Any changes here are just going to create conflicts and I don't think it's too awful to borrow the cluster's CA cert from tsh or cut and paste it from our tlscacerts for testing purposes.