Consider rc semver compatible for the linker

#### Feature

Currently the linker only considers only non-rc versions to be backwards compat https://github.com/alexcrichton/wasmtime/blob/main/crates/environ/src/component/names.rs#L194.

This is quite annoying when creating an rc for a new minor versions that is intended to be backwards compat.

Example:
We are currently supporting version 1.1.x of our wit in the host. We want to start development of a new, backwards compat 1.2.0 release, optimally publishing the first draft as 1.2.0-rc1. The problem becomes that if we want to support both 1.1.x and 1.2.0-rc we need to implement all the host functions twice, otherwise some of our users would get linking errors.

The proposal would be to consider rc versions to be backwards compat if they do not increment the major component. It's probably right if rcs are not considered to be semver compatible with each other, as during development of an rc apis often change.
So
```
/// * `foo` => `None`
/// * `foo:bar/baz` => `None`
/// * `foo:bar/baz@1.1.2` => `Some(foo:bar/baz@1)`
/// * `foo:bar/baz@0.1.0` => `Some(foo:bar/baz@0.1)`
/// * `foo:bar/baz@0.0.1` => `None`
/// * `foo:bar/baz@0.1.0-rc.2` => `None`
```
would become
```
/// * `foo` => `None`
/// * `foo:bar/baz` => `None`
/// * `foo:bar/baz@1.1.2` => `Some(foo:bar/baz@1)`
/// * `foo:bar/baz@0.1.0` => `Some(foo:bar/baz@0.1)`
/// * `foo:bar/baz@0.0.1` => `None`
/// * `foo:bar/baz@0.1.0-rc.2` => `None`
/// * `foo:bar/baz@0.1.1-rc.2` => `Some(foo:bar/baz@0.1)`
/// * `foo:bar/baz@1.0.0-rc.1` => `None`
/// * `foo:bar/baz@1.1.0-rc.1` => `Some(foo:bar/baz@1)`
```

#### Benefit

Allow platform maintainers to more easily ship new versions of their api without duplicating a lot of code.

#### Implementation

From what I can tell only the alternate_lookup_key function would need to be adjusted to handle the new cases.
https://github.com/alexcrichton/wasmtime/blob/main/crates/environ/src/component/names.rs#L199

#### Alternatives

One option that comes to mind is bumping the minor version on every change, but that makes it very difficult to keep the wit version in sync with the version of the platform.

Another is not publishing the new version of the wit until it is fully ready, but that makes it difficult to test with users and iterate on the new version.

A third option is to implement both the rc and the old version, but I would like to avoid that duplication.