Add support to specify an Android SDK in ANDROID_HOME (fixes #463)

[rmartin16]

Changes

• Fixes Add support for ANDROID_HOME environment variable #463
• The file path in ANDROID_HOME now takes precedence over ANDROID_SDK_ROOT
• The eventual file path for the SDK used is passed both as ANDROID_HOME and ANDROID_SDK_ROOT when Android commands are run in the shell.
• Behavior summary:
  • No environment variables set
    • Briefcase's SDK is used
  • Only ANDROID_HOME is set
    • If it's an SDK, it is silently used
    • If it's not an SDK, a warning is issued it isn't an SDK and Briefcase's SDK is used
  • Only ANDROID_SDK_ROOT is set
    • If it's an SDK, a warning is issued that ANDROID_SDK_ROOT is deprecated but it is used
    • If it's not an SDK, a warning is issued it isn't an SDK and Briefcase's SDK is used
  • Both ANDROID_HOME and ANDROID_SDK_ROOT are set to the same value
    • Falls back to as if only ANDROID_HOME was set
  • Both ANDROID_HOME and ANDROID_SDK_ROOT are set to different values
    • A warning is issued that ANDROID_HOME takes precedence over ANDROID_SDK_ROOT
    • If ANDROID_HOME is a valid SDK, it is used
    • If ANDROID_HOME is not a valid SDK, a warning is issued it isn't an SDK and Briefcase's SDK is used

Notes

• I broke with the recommended implementation because I think it can imposition the user too much.
• For instance, erroring if ANDROID_HOME and ANDROID_SDK_ROOT are set to different file paths.
  • This isn't inherently problematic for Briefcase...at least based on my implementation.
  • However, erroring like this would require users to change their environment just to run Briefcase.
• As part of this, I am also setting the SDK file path in both ANDROID_HOME and ANDROID_SDK_ROOT for subprocess calls
  • This is primarily because if the user has a bad setting for ANDROID_SDK_ROOT and Briefcase only sets ANDROID_HOME, the ANDROID_SDK_ROOT setting will leak in to subprocess calls.....therefore, the user would need to unset ANDROID_SDK_ROOT to be able to run Briefcase.
  • So, it seems reasonable to me for Briefcase to simply mask this scenario since we already have a known valid SDK.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

I've pushed some minor language tweaks, but otherwise this looks good.

In terms of the specific behavior you've implemented - those changes both makes sense to me. Setting both environment variables removes all doubt over the environment that is used at runtime; and warning the user about a setting inconsistency but recovering acts as a canary that something isn't right while not getting in the way of progress.

I'll leave the final approval to Malcolm in case I've missed something in my analysis, but as far as I'm concerned, I'm happy.