Add some instructions for testing changes with the simulator

[dae]

No description provided.

[mikehardy]

Hmm - we have an effort called "doctor" here https://github.com/ankidroid/Anki-Android-Backend/blob/main/tools/doctor.sh

I think it would be easier than a bunch of installs and patches to make sure that was actually working (I think it is working? It was last time I went through) then this PR/doc should just boil down to 2 steps in the main README saying "run doctor" / alter this line in AnkiDroid/build.gradle ?

[dae]

A few advantages of the approach described in this PR:

• it doesn't require docker or building the docker images
• it doesn't require installing cross
• it doesn't require installing 3/4 of the architectures
• it doesn't require building 3/4 architectures each time
• it describes how the user can use a python venv instead of using a system-wide install
• it describes how to install the appropriate ndk, instead of just telling you it's missing

Personally, when I am working on a project and discover a dependency has an issue, I want to know how I can make an experimental change to that dependency, and how I can most simply rebuild the parent project with the changes. I found the existing docs on this repo lacking here - the README only covers using the official release, and ENVIRONMENT spends most of the time talking about cross compilation and doesn't describe how to actually use the generated artifact.

[dae]

(updated so unit tests work too)

[mikehardy]

Good feedback - I'd like the process to be as automated as possible, so I'd like doctor to work but even if doctor was working, without some effort to trim it's weight (all the arches and cross-compilation) this is still a valid optimization as the docker/cross stuff is pretty cumbersome. In the end I'm fine with incrementalism in practice and will merge this but organizationally I want to peel a few things out for tracking

• doctor can do a better job of installing ndk, I've automated that in other places (automate ndk install in doctor script #195)
• doctor should install / use python virtual env by default I think, I've automated that in other places too (doctor script should use python venv to spare global python environment from pollution #196)
• doctor should offer the option of using one arch / no docker (related Compile only for the host platform when using debug. #40 for the build itself, doctor should offer use of one arch / no cross compile #197)
• README should discuss how to vary dependencies when working on picks/updates to rslib-bridge/anki submodule (README needs instructions explaining how to vary anki fork dependency #198)