refactor: move to expo

[Harjot1Singh]

Summary

Yes... please excuse the size of this 😅

It's been a while since we've done significant work on this project. Since then, expo has become an excellent choice of tooling to reduce the overall maintenance burden. This PR fundamentally moves us over to expo, with a number of tooling changes that will simplify working with the project successfully.

Expo CNG

Continuous native generation means that we no longer have to maintain specific ios and android folders - these are generated on build with the appropriate config. Much more stable & deterministic across different setups.

Expo Router

Instead of setting up the screens and structure for defining screens ourselves, expo-router uses filesystem-based routing. Since the convention is public, it makes it much easier for everyone to know where and how to add new routes. It also comes with deeplinking OOTB. It's powered by react-navigation under-the-hood, which is what we were explicitly using beforehand.

Atomic Design

Organising component code has been made clearer by adopting Atomic Design. Components must fit into atoms, molecules, organisms, templates, and templates are always rendered by routes, to improve testability and reusability. We have not figured out a convention for layout routes just yet.

We should adopt this for our design library/system.

Logging

We're using a proper logger, with module-scoped messages O_o

Config

Env variables can be set in the config/environment/config.{environment}.ts files. Running the app with APP_ENV=next will inject the values in config.next.ts and so forth. TS files have been used to ensure we can catch missed declarations/fields.

By default, APP_ENV=local, so config.localts is used. This file is gitignored and so you should copy config.example.ts over as config.local.ts.

Mise/Simplified Tooling

We now recommend using mise to install the different versions of tools, in .ruby-version, .node-version, and .java-version. You can also use other tools separately, such as asdf, rvm, and nvm.

EAS build + submit

Now that we're using the eas-cli to build and submit (in local mode), there is no need for fastlane, homebrew (graphicsmagik), or ruby! Simplified tooling and reduced maintenance burden :)