Add documentation & flexibility to the way Consul Connect Leaf Certificate CNs are calculated

#### Feature Description

##### Context & Background

Currently, the CN on a Consul Connect Leaf Certificate requested through the /agent/connect endpoint follows a quite unique and non-standard syntax which isn't present anywhere else in the system.

One can only find a rationale for this by looking closely at the code and some of the comments attached to it (as well as by tracing back PRs, commits, etc.): https://github.com/hashicorp/consul/blob/master/agent/connect/common_names.go

Problem with this approach is that the CN cannot really be inferred at runtime (for dynamic config purposes) which can be quite limiting, besides leaving the consumer with a proprietary / opinionated implementation as the only available option

*** It is understood that SNI (service discovery chain) is not being used here because of a 64-character constraint in the X509 spec

##### Suggested Features

- First and foremost, these internals should be documented and explained in detail, probably here: https://www.consul.io/docs/connect/connect-internals
- The documentation for connect API should also link you to this very relevant information
- There should be an API endpoint under /agent/connect which allows you to easily and reliably get the calculated CN for a specific service name
- Besides having this as a "default" behaviour, the API should also allow consumers to provide a specific CN (or maybe SAN?) to the CSR. This optional parameter can be validated using regular expressions, etc. to make sure it is constructed adequately and in compliance with what connect internals require
- Another idea off the top of my head is to keep this functionality when internal CA is being used, but allow greater flexibility (and decoupling) on the CSR when Vault has been configured as the CA; then Vault can perform proper validations, enforce certification chains and deal with any additional security concerns.
- If the "cluster id" (first 8 digits of trust domain UUID) is absolutely necessary for internal functionality, then this value should also be available through the API (and visible for consul template for example).

#### Use Case(s)

This is extremely relevant for any application which does native integration with Consul Connect and relies on the certificate's CN for establishing mutual TLS.

One very obvious example would be Java, where mutual TLS is delegated to keystores / truststores containing the certification chain. CN is a key element in these cases, and one cannot expect every application to be fully SPIFFE / SPIRE compliant just yet.

This is the specific use case which put us in this conundrum:

https://github.com/gugalnikov/presto-consul-connect

Presto is a Java-based distributed SQL application (with a complex internal architecture) which we are integrating natively with Consul Connect. A contribution was made recently to add pluggable certificate authenticators to the tool for this purpose:

https://prestosql.io/docs/current/develop/certificate-authenticator.html

The plugin works quite well and Consul Connect can secure both internal and external communication to the Presto coordinator and workers, but the aforementioned situation with Leaf Certificate Common Names is really limiting our flexibility when it comes to dynamic provisioning, scaling, etc.