connect: add SPIFFE Workload API and SPIRE-like attestations support

#### Feature Description
Enhance Consul Connect to support SPIFFE Workload API (https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE_Workload_API.md) and to support attestation processes similar to what’s implemented in SPIRE (https://spiffe.io/spire/concepts/).

- I understand that Consul already support the SPIFFE SVID format today. However, Consul does not support SPIFFE Workload API, which mandates the absence of direct client authentication to assign identity to the calling workload.
- I think supporting SPIFFE Workload API would simplify Consul configuration management by not requiring to specify service definitions in the config files.
- For example, when an application such as Envoy launches, instead of calling Consul Connect for the private key of “app1”, the application, aka the “workload”, would ask “who am I?” to a local Consul agent running in client mode via UDS. The local Consul agent would be responsible to perform an out-of-band authenticity check to determine which identity this “workload” should be assign to and return a matched SVID. On linux, such check could be based on the agent interrogates the node’s kernel to identify the process ID of the caller. The caller and the Consul agent must run on the same node. The process ID would then be used to lookup other info such as k8s kubelet or an AWS Instance identity document. These additional info would be used to match a pre-registered service definition from the catalog.
- In this model, the identity of a workload is lazily provisioned at runtime only based on where the workload is running on, and what identity that environment had be registered to.
- Personally, I find this model to be compelling because a workload cannot spoof to take on a service identity if it’s running in the wrong environment. In addition, I don't need to embed every details about a service definition in the Consul agent config files.

#### Use Case(s)
The Workload Attestation and Node Attestation use cases described below expands the traditional role of a service registry to also track "workloads" and "nodes". A "workload" is more similar to a service definition but can also represent batch jobs and serverless functions that are not always on. A "node" maps more closely to a Unix server, a k8s service account, or AWS instance identity. Expanding the service registry scope to track these additional components helps to better managing IT resources across more distributed, dynamic environments.

1. Workload Attestation - when a workload application such as Envoy calls Consul Connect via the gRPC ADS interface (assuming this is accessible via an agent in client mode), the agent will use the caller's process id to determine a matching registered service definition and return the workload identity as an SPIFFE SVID.

The matching/ workload attestation process is implemented based on a pluggable framework similar to what's implemented in SPIRE. Consul agent clients will be able to use plugins specific to the hosting environment (e.g. Unix, k8s, or AWS) to gather additional information based on the process Id such as uid, gid, or k8s namespace. The information will be compared against metadata in the registered service definitions. Only Consul agent client mode is needed to participate in workload attestation. Consul server should not be needed.

2. Node Attestation - this process is used for a consul agent client to obtain an SVID for itself from its Consul server. In this model, the consul agent client represents a node identity that's different from the workload processes. To support this, Consul server needs to also support a set of node attention plugins.

I’m interested to work on this feature and eventually submit a pull request. Before I dive in, is this enhancement desirable for the Consul ecosystem? Thanks!