[ci] Switch Android unit tests to LUCI

[stuartmorgan-g]

This moves Android unit tests from Cirrus to LUCI. In order to accomplish this:

• Switches the Android LUCI bots from JDK 11 to JDK 12, to resolve a crash when compiling camera_android unit tests with 11.
• Adds wrappers to SDK checks where necessary for testability, since the hack to override Build.VERSION.SDK_INT in unit tests (which was already giving warnings when run with JDK 11) no longer works at all in JDK 12.

Part of flutter/flutter#114373

[stuartmorgan-g]

@reidbaker What do you think of the patterns I'm introducing here?

The background here is that the version of JDK 11 we have available for LUCI has a crash when compiling the camera_android unit tests, and @yusuf-goog wasn't able to find a version of 11 that had the fix, so this updates us to JDK 12 instead. It turns out that the hack we were using in tests to swap out Build.VERSION.SDK_INT in tests completely stopped working in 12+ (in 11 it was giving us "illegal reflection" warnings about how it would be removed in the future; apparently they weren't kidding), so I replaced it with wrappers instead. I'm very open to feedback on how we structure that:

• For simple cases I used DI for the wrapper, since I generally think DI is much better than globals. On the other hand, the thing I'm wrapping is already a global, so doing it via a global everywhere is a plausible option.
• For camera_android, where it was spread throughout the codebase, I opted for a global, but I could probably DI everything if we want to go that route.
  • I also made named helpers, since that's something we'd talked about before; I went back and forth on having the named helpers in the global object, vs the global just being dumb and leaving individual objects to have private named wrappers. In a couple of places we needed the same conceptual check so I opted for centralized, but I don't have strong feelings about it either way.

I'm also definitely open to completely different ways of doing this if you have a preferred pattern.

[reidbaker]

Great readability improvements.

[reidbaker]

I find these types of classes aid in readability a ton. That said it is even better when there are breadcrumbs to the source of truth but are annoying to find during a refactor and this is already a net improvement. To that end I have added suggestions with links to the android docs for at many as I could find.