rpc: improve RPC logging

Building on #10250 (using the interceptor proposed in #10574) we can make Consul easier to operate by adding logging for every RPC request. Initially these could be DEBUG logs, but we might also consider making them INFO level (the equivalent HTTP request log is INFO level).

On each request we should log the RPC call, along with all of the labels used on the metric for #10250.

In addition to those labels, we should add identifiers for the request. Each request type should implement an interface that returns the full identifier with namespace and partition. For example:
* `RegisterRequest` would return an identifier with `ID`, and if applicable `CheckID`, and `ServiceID`.
* `CheckServiceNode` would return a similar identifier
* `KVSRequest` would return an identifier with `DirEntry.Key`
* `ConfigEntryRequest` would return an identifier with `Entry.Kind` and `Entry.Name`
* etc

We may also want to include other identifiers, such as KV operation.

To gather all these identifiers for the log entry, we could implement the following interface on all request types:

```go
type RequestIdentifier interface {
// RequestID returns an identifier for the entity being written (for writes) or requested (for reads)
RequestID() string
// RequestMetadata may return pairs of request metadata used to log the request.
RequestMetadata() []string
}
```

In addition to the identifier and metadata, we can also log the following:

* error text (or error category) from the response
* accessor ID from the ACL token

Start by reviewing the interceptor proposed in #10574 and the RPC request types referenced here. Define how request identifiers, metadata, errors, and ACL accessor IDs should be collected and logged, then verify that every RPC request produces the intended log entry and labels.

Written by the indexing model from the issue text.