feat: Android adapter

[mwcampbell]

I think the Android adapter is now complete enough to start reviewing.

My current main test case and demo for this adapter is this sample project, which uses a slightly modified version of GameActivity: https://github.com/[mwcampbell/xilem-to-do-mvc-android](https://github.com/mwcampbell/xilem-to-do-mvc-android)

We may debate the division of responsibilities between the native and Java code. Perhaps it would be better if more things were implemented on the native side. To some extent, I just implemented things on the Java side when it was more convenient to write them in Java because of the number of Java method calls required. But I think there's also some logic to my decisions. For example, the current Java implementations of the various event-sending methods post asynchronous requests to the UI thread, but one could imagine an alternate implementation that assumes it's being called on the UI thread and sends the events synchronously. The lower-level Adapter type is designed to support such alternate implementations, as mentioned in that types documentation, though no such implementations exist yet (as they'd require a different Android activity class and using something other than winit). I also thought it made sense to store Android-specific state, such as the accessibility focus and current hover (explore-by-touch) node, on the Java side, but am willing to revisit that.

I guess we should have CI tasks to verify the Java code formatting and check that the prebuilt .dex file matches the source code. I included the script I'm using to build the .dex. It works on my Mac with my particular Android SDK installation. I don't know if it's really necessary to target Java 7, but I remembered reading that Java 8 and above required some tools for desugaring lambdas and possibly other newer features, and I didn't want to try to figure out how to make that work outside of a typical Gradle project. As for whether we should actually use a typical Gradle project, I don't know if that can build a .dex outside the context of a full Android application.

[DataTriny]

Very nice work! There are probably too much back and forth when populating nodes and we will likely have to optimize this part, but I'm happy with shipping something that works and improve later.

• Please make sure to implement Debug on public facing types.
• On the documentation of structs, have the first paragraph be short and separate it from the rest with a blank line so that it don't clutter the documentation pages.
• You'll likely want to update the copyright year on all files, sorry about that.
• Don't forget to update the main README. as well as the common crate one.

[DataTriny]

CI steps to enforce code formatting on the Java side and check the dex file must also be added. Checking the dex file is particularely critical.

[DataTriny]

I think it would make sense to merge the Java formatting step with the existing fmt job. It's wasteful to spin a container and clone the repo again just to check one file. Feel free to rename the steps in the job though, so that it's clear what is going wrong in case of failure.

[DataTriny]

Congratulations on this one!