(cargo-release) version 0.8.0

…ility. (#414)

Fixes #413.

Prior to this commit, the `uniffi-bindgen` command would use `cargo metadata`
to discover the version of uniffi being used by the target crate, and would
error out if did not match the version of uniffi-bindgen itself.

Unfortunately, this approach is not reliable when the target crate is being
compiled as a dependency rather than as the primary crate. The build process
may pick a version of uniffi based on the `Cargo.lock` of the primary crate
or based on resolving compatible versions with other dependencies, while
while `cargo metadata` will report the verison of uniffi that would be used
if you built the target crate in isolation.

To avoid these potential sources of error, this commit switches to an approach
based on static assertions, in two halves:

* When generating the Rust scaffolding, we emit a call to a new
  macro `uniffi::assert_compatible_version!(v)` and pass it a static
  string constant representing the version of uniffi_bindgen that
  generated the code.

* When compiling the resulting code as part of a uniffied crate, the
  `assert_compatible_version!` macro will check the static string against
  the version of uniffi being used in the build, producing a compile-time
  failure if they do not match.

This is a slightly worse consumer experience because the error message
isn't as good, but it's more reliable, so I think it's a win overall.

Be warned, I had to do some terrible things to perform this check in
a compile-time const context on stable Rust :-/

I've also taken the opportunity to try out the `trybuild` crate to
write a testcase for the actual compiler error message generated
by the macro. As we come to iterate more on the developer experience,
I expect `trybuild` or something like it will become pretty important.

Based on recent experience with trying to use this on an
an existing Swift+Rust project.

For demonstration purposes we mark the interface as threadsafe,
meaning we need to drop all `&mut self` functions and wrap
`self.items` in a suitable wrapper - `RwLock` in this case.

This is done in support of [ADR-0004](
https://github.com/mozilla/uniffi-rs/blob/main/docs/adr/0004-only-threadsafe-interfaces.md),
which will contain a link to this PR/commit to show an example of the
kind of modifications interfaces  need to become threadsafe.

Move the `fileprivate` access modifier to the extension declaration to reduce swiftformat errors in generated code. This required a separate extension declaration for the protocol conformance because `fileprivate` could not be applied to the same declaration as the one declaring the protocols.

This attempts to the document the reasons why we think removing
support for uniffi managing thread-safety is a bad idea and
formalizes a decision to remove that support.

The set of types is used in multiple places during FFI creation. When
the data structure does not guarantee the order of elements, such as
HashSet, the resulting generated source code is not deterministic. Using
a BTreeSet resolves this issue by providing a well-defined element order
over which the the set may be iterated.

Co-authored-by: Matthew Finkel <sysrqb@torproject.org>

This is similar to our examples, but it's intended to be contrived and to
ensure we get good test coverage of all possible options - particularly for
future changes.

It's in the "fixtures" directory so it doesn't even need to make a cursory
effort to be a "good example"; it intentionally panics, asserts params are
certain values, has no-op methods etc. If you're trying to get your head
around uniffi then the "examples" directory will be a much better bet.

I recently updated the docker image that we use to run CI, which
seems to have perturbed the version of Rust being used, which has
subtly changed the expected error output from `trybuild`. This
should get CI passing again.

Now that [adr-0004](https://github.com/mozilla/uniffi-rs/blob/main/docs/adr/0004-only-threadsafe-interfaces.md)
has been approved, we should deprecate non-threadsafe interfaces ASAP,
to ensure that consumers have as much time as possible to migrate
before we drop support for non-threadsafe interfaces entirely.

We are leaving the Threadsafe example as the only one
which supports a non-threadsafe interface until we actually
remove support for non-theadsafe interfaces.