Update cat_facts example for Crux 0.17, and update APIs for crux_kv, crux_platform and crux_time

[StuartHarris]

note: these are breaking changes

crux_kv

• [x] Add #[derive(Facet)] where missing
• [x] Remove Value as we can just use Option<Vec<u8>>
• [x] Use KeyValueResult across the bridge (instead of various Result monomorphisations), so that we can #[derive(Facet)]
• [x] Change enum struct variants to tuple variants where it makes sense, to make the API more ergonomic and pattern matching easier

crux_platform

• [x] Add #[derive(Facet)] where missing

crux_time

• [x] Use our own Instant instead of std::time::SystemTime across the bridge, so we can #[derive(Facet)]

cat_facts example

• [x] removes shared types lib
• [x] adds CoreFFI
  • [x] uses crux_core::bridge::Bridge
  • [x] introduces new features for uniffi and wasm_bindgen, which means that web-yew and cli shells no longer include a bridge
• [x] add codegen binary, for facet based typegen of Swift, Kotlin, TypeScript, and bindgen for Android
• [x] use resolver = "3"
• [x] update iOS app, uses uniffi feature
• [x] update Android app (including deps, moving from gradle to kts), uses uniffi feature
• [x] update web-nextjs (including wasm package in generated folder), uses wasm_bindgen feature
• [x] update web-yew, doesn't use uniffi or wasm_bindgen features, so no bridge
• [x] update cli, doesn't use uniffi or wasm_bindgen features, so no bridge
• [x] adds a Justfile for each shell, so that you can just cd into the relevant directory and run just dev to get going.

all examples

• [x] update to use new APIs from crux_kv, crux_platform and crux_time

[StuartHarris]

The example changes look good at a quick read, but I do not liket the capability changes - we've lost the distinction between the protocol API and the core facing API, and erasing that distinction makes them both worse for their respective purpose.

I feel like this keeps coming back to confuse us, we should probably introduce a convention that the FFI "wire" types are in a protocol module in each capability, to make this clearer.

You're right. I think it's a really good idea to have a mod protocol for all the FFI wire types. I'll do that. We have to own these types though, so we can annotate them. The exception is Option<T> at the moment, although Result<T, E> may be coming (https://github.com/facet-rs/facet/issues/887) soon (but in the meantime, I'll add distinct result types for the wire). Let me re-work this.

[charypar]

Yea, we do need to own the protocol types, and they also need to serialize well into various formats (esp. JSON which will probably be common). That's also what then makes them kinda nasty to use in normal Rust code, they are really more of an FFI format...

[StuartHarris]

The confusion was due to inward-facing types needing to implement Facet in order to be part of the Event enum. I've since updated facet_generate to support #[facet(opaque)] correctly, so that now fields in structs and in struct or tuple variants can reference types that don't need to implement Facet. This means we can use the capabilities correctly (although I moved all the protocol types to a protocol module, and implemented Facet on them where missing).