Keeping it up-to-date and also testing it

…tations (#1482)

WIT 'use' statements are represented as Type::Id(_) Types in this codebase, and get
translated to Rust type aliases in the generated Rust bindings.

Since these aliases may be located at different module paths, creating a StreamPayload
or FuturePayload implementation for more than one of these paths will cause the Rust compiler
to complain about conflicting trait implementations for the same type.

This commit solves this issue by dealiasing payload types of the form Type::Id(_) when generating
a key for the future_payloads and stream_payloads maps. This means each alias set will have at
most one implementation of these traits.

Fixes issue 1432

* Prepare for wasm-tools 0.245

* adapt to an even newer version of wasm-tools

* adapt to new Parameter type

* Update to crates.io-based versions of crates

---------

Co-authored-by: Alex Crichton <alex@alexcrichton.com>

Co-authored-by: Alex Crichton <alex@alexcrichton.com>

* Generate nominal IDs for all bindings generation

This commit leverages bytecodealliance/wasm-tools#2447 to make many
existing and future problems much easier in `wit-bindgen`. Namely a
`TypeId` now uniquely identifies a type to be generated rather than
simultaneously representing both an import and an export in some
situations. This isn't immediately leveraged in bindings generators just
yet but it's intended to open up the doors to benefitting from this in
the future.

* Rely on nominal type ids in the rust generator

No major changes just yet, but this shows some examples of removing
non-obvious logic in bindings generation enabled by nominal type ids.

* Fix Go CI

* merge equal types

* fix

* add test

* Refactor type equality algorithm structure

* Handle `alias == primitive` by juggling typedefs/`Type::Id` a bit
  more carefully.
* Avoid using `_ => false`
* Fix handling of `own`/`borrow` and `future`/`stream` to be more
  uniform like the rest of the algorithm.
* Avoid special-casing resources, but for now consider them always
  not-equal.

* Adjust CLI flag handling

* Refactor how structurally-equal types are generated

Leverage the recent support for nominal type IDs to remove some
now-no-longer-necessary infrastructure. This additionally overrides the
`define_type` method in the Rust generator to handle aliases at one
location instead of in multiple locations.

---------

Co-authored-by: Alex Crichton <alex@alexcrichton.com>

Follow-up to #1468

An attempt to get `cargo binstall wit-bindgen-cli` working, copied
mostly from the `wasm-tools` repository.

Follow-up from #1468 to account for work in #1526.

* rust: Reimplement how stream/future payloads work

Previously stream/future payload were generated by collecting the set of
types used in `future` and `stream` types in a WIT, rendering them to a
string, deduplicating based on this string representation, and then
generating various impls-with-vtables. This stringification strategy
unfortunately falls down in a few situations such as:

* Type aliases in WIT render as two names in Rust, but they're using the
  same Rust type.
* Types with the same definition, but in multiple modules, will have two
  different paths in Rust but alias the same type.
* Primitives may be used directly in streams/futures but then
  additionally used as a WIT type alias.

In all of these situations it's effectively exposing how Rust requires
at most one-impl-per-type-definition but the stringification/deduping
was just a proxy for implementing this restriction and not a precise
calculation. Using the work from bytecodealliance/wasm-tools#2447 as
well as #1468 it's possible to do all of this without stringifying.
Specifically #1468, transitively enabled by
bytecodealliance/wasm-tools#2447, enables building a set of equal types
that the Rust generator knows will all alias the same type definition.
Using this it's possible to translate a payload to its "canonical
payload" representation ID-wise and perform hashing/deduplication based
on that. This in turn solves all of the issues above as well as previous
issues such as #1432 and #1433 without requiring the workaround in #1482.

The end result is that all of these various bugs should be fixed and the
Rust generator should be much more reliable about when exactly a trait
impl is emitted vs not.

Closes #1523
Closes #1524

* Try fixing CI

* Fix typo

* Fix rust CI

[automatically-tag-and-release-this-commit]

Co-authored-by: Auto Release Process <auto-release-process@users.noreply.github.com>