[core] no_std support

[ianthetechie]

At some point we'll want to explore support for no_std platforms. Our initial focus is on major mobile operating systems, which have support for the full standard library, but certain embedded platforms we may target in the future may not.

This issue tracks known steps we'll need to take to support no_std:

• non-UniFFI interface: UniFFI requires the standard library, particularly making use of things like std::sync::Arc in constructors, and types like std::time::SystemTime for mapping timestamps.
• We use std::collections::HashMap a few places; could probably replace with alloc::collections::BTreeMap; we can also use Vec from alloc
• NavigationController currently uses a Mutex for internal state mutation. This is arguably an antipattern and breaks the clean "functional core / imperative shell" pattern. We should probably rearchitect this to return a new controller state (which must be saved by the caller) before v1.0.
• Upstream changes to thiserror to support no_std: core::error, no_std dtolnay/thiserror#304

[ianthetechie]

Another thing to note is that, for the longest time, core::error::Error was not stable. That changed today with the release of Rust 1.81 :) So that removes one more constraint on things.