Add DefaultEndpointResolver to the orchestrator (#2577)

## Motivation and Context
This PR adds `DefaultEndpointResolver`, a default implementer of the
[EndpointResolver](https://github.com/awslabs/smithy-rs/blob/1e27efe05fe7b991c9f9bbf3d63a297b2dded334/rust-runtime/aws-smithy-runtime-api/src/client/orchestrator.rs#L182-L184

)
trait, to the orchestrator.

## Description
Roughly speaking, the endpoint-related work is currently done by
`make_operation` and `SmithyEndpointStage`, where `make_operation`
constructs endpoint params and applies an endpoint resolver and the
`SmithyEndpointStage` later updates the request header based on the
resolved endpoint. In the orchestrator world, that work is handled by
`DefaultEndpointResolver::resolve_and_apply_endpoint`.

The way endpoint parameters and an endpoint prefix are made available to
`DefaultEndpointResolver::resolve_and_apply_endpoint` is done by
interceptors because they _may_ require pieces of information only
available in an operation input struct. The place that has access to
both an operation input struct and a config bag happens to be an
interceptor.

There are two interceptors `<Operation>EndpointParamsInterceptor` and
`<Operation>EndpointParamsFinalizerInterceptor` per operation. We pass
around endpoint params _builder_ through interceptors to allow it to be
configured with more information at a later point; An end point
parameters builder is first initialized within the
`ServiceRuntimePlugin` with the field values obtained from the service
config, and is stored in a config bag. The finalizer interceptor "seals"
the builder and creates the actual endpoint params before it is passed
to `DefaultEndpointResolver::resolve_and_apply_endpoint`. These
interceptors implement `read_before_execution` because they need to
access an operation input before it gets serialized (otherwise,
`context.input()` would return a `None`).

## Testing
Replaced `StaticUriEndpointResolver` with `DefaultEndpointResolver` in
`sra_test` and verified the test continued passing.

UPDATE: The test currently fails in the `main` branch (it returns a
`None` when extracting `SigV4OperationSigningConfig` from the config bag
in `OverrideSigningTimeInterceptor`, hence `unwrap` fails), and by
merging the `main` branch this PR no longer passes the test, but it does
not add new failures either.

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._

---------

Co-authored-by: Yuki Saito <awsaito@amazon.com>