This patch introduces a new `systemspanconfig.Target` type which is
intended as in interemediate representation for system span config
targets throughout the `spanconfig` package. It ties together a
targeter tenant ID with a targetee tenant ID (along with validation
to ensure secondary tenants don't target other tenants).

We also reserve a `SystemSpanConfigSpan` at the end of the System
range. This allows us to assign special meaning to key-prefixes carved
out of this range (when stored in `system.span_configurations`).
By ensuring this span is carved at the end of the system range, we can
ensure that the host tenant does not install span configurations to this
span directly.

We define special key prefixes for system span configurations in this
range and establish a mapping between a Target <-> span using `Encode`
and `Decode` methods. This is useful when we store sysytem span
configurations in `system.span_configurations`  given its schema. Ditto
for reading from the table.

We'll make use of the `Target` in upcoming PRs, specifically in the
`KVAccessor`, `KVSubscriber`, and (the upcoming)
`SystemSpanConfigStore`.

The `KVAccessor` will construct `Targets` using tenant information from
the context as the targeter tenant. It'll use the
`roachpb.SystemSpanConfigTargets` supplied to it by RPCs (See cockroachdb#75615).
The encoding/decoding methods will be used when writing to/reading from
`system.span_configurations`.

While the existing `roachpb.SystemSpanConfigTarget` is sufficient
for our use in the `KVAccessor` (which runs on SQL pods), the richer
structure is motivated by the desire to also use this type in the
`KVSubscriber` (when receiving system span config events) and
`SystemSpanConfigStore` (which is an in-memory representation of the
system span config state). Down in KV we want to distinguish between a
tenant installed system span config on its entire keyspace vs. a host
tenant installed system span config over a tenants keyspace.

Release note: None