### Motivation

The latest draft of the ARC spec[0] includes moving where the
presentation limit is used. Before it was baked in when a client
constructed a credential request, but now it has moved to when a client
makes a presentation from a finalized credential. This PR updates the
internals and API surface to reflect this change.

### Modifications

- Defer passing the presentation limit until a presentation is made.

### Result

Align more closely with the published draft.

### API breakage

It's expected that this will result in the following _breaking_ API
changes:

```diff
- P384._ARCV1.PublicKey.prepareCredentialRequest(requestContext:presentationLimit:)
+ P384._ARCV1.PublicKey.prepareCredentialRequest(requestContext:)
```

```diff
- P384._ARCV1.Credential.makePresentation(context:)
+ P384._ARCV1.Credential.makePresentation(context:presentationLimit:)
```

As this is behind an underscored namespace, we deem this an acceptable
break.

[0]: https://datatracker.ietf.org/doc/draft-yun-cfrg-arc/

### Motivation

The ARC API surface had no Sendable conformance.

### Modifications

Add Sendable conformance to ARC API types, which are all value types.

### Result

Easier to use ARC API types in concurrent contexts.

)

### Motivation

The use of `Data.subdata(in:)` results in needless copies when decoding
fields from bytes. Additionally, the use of a long chain of
`Data.append(_:)` without a call to `Data.init(capacity:)` or
`Data.reserveCapacity(_:)` can result in needless reallocations.

### Modifications

- Remove unused `EncodeInt` and `DecodeInt` functions. They were unused
before this PR but are there from when ARC credential serialization
included the presentation limit. `DecodeInt` also happened to be
incorrect and would crash when called with a slice.
- Add some useful utility methods for popping bytes from a view without
copying.
- Add some generic functions for encoding and decoding
`FixedWidthInteger` types along with tests for concrete types over
`Data` and slices.
- In ARC decoding, replace the use of `Data.subdata(in:)` with code that
uses the `Data.Subsequence` slice (which happens to be `Data` since the
type is self-slicing).
- In ARC encoding, reserve enough capacity in the resulting `Data` when
the sizes are known to reduce allocations.

## Results

More performant serialization and deserialization for ARC types.