[HTTP 1.x] Add legacy crates to maintain http@0.x support during migration

[drganjoo]

This PR introduces two new legacy crates (aws-smithy-legacy-http and aws-smithy-legacy-http-server) that maintain support for http@0.x
while the codebase transitions to http@1.x.

Background

As part of the HTTP 1.x migration effort (see branch feature/http-1.x), we're adding support for generating server SDKs that depend on http@1.x via a new http-1x codegen flag. However, we need to maintain backward compatibility with http@0.x for existing users.

Why Legacy Crates?

Initially, we attempted to pin dependencies to the last versions that supported http@0.x. However, this approach failed because:

• The codegen tests produce SDKs with path dependencies on crates
• These crates transitively depend on the same crates we were trying to pin
• This created version conflicts that couldn't be resolved with simple pinning

Solution

Creating dedicated legacy crates solves this problem by:

1. Isolating http@0.x dependencies - Clear separation between http@0.x and http@1.x codepaths
2. Easier maintenance - We can port changes back and forth between versions without checking out old commits
3. Simpler development workflow - Developers don't need to switch branches/commits to maintain http@0.x support
4. Clearer intent - Makes it explicit which code supports which HTTP version

Changes in this PR

• Added aws-smithy-legacy-http crate (forked from aws-smithy-http with http@0.x support)
• Added aws-smithy-legacy-http-server crate (forked from aws-smithy-http-server with http@0.x support)
• Updated rust-runtime/Cargo.toml to include both legacy crates in the workspace

Note

This PR is split out from the main http@1.x work to make it easier for reviewers to evaluate just the legacy crate additions separately from the codegen changes. By default, http@0.x remains the default - the http-1x flag must be explicitly enabled to use http@1.x.