Install a new version of the Android tools along with the old one.
Keep the old version as the current version for now to avoid breaking
builds, but still make the new version available.
This will also make future upgrades more smooth as well.

Switch to the new URL scheme for SDK downloads,
which also has switched to using zip files instead of .tar.gz files.
Note that the new packaging format
no longer has a top-level `android-sdk-linux` folder.

Move the `build_tools` and `platform` attributes under `sdk`,
as they are only used with the SDK-related states.

Reinstate `if_missing` for the SDK `archive.extracted` state to ensure
that the new archive will be extracted if the old one is present,
so that the SDK has the correct directory layout.
This also means ownership will only be updated for that file
(the `android` binary), so add a `file.directory` state to handle
fixing the ownership for the rest of the extracted files,
and fixup the requisites as necessary.

The SDK layout has changed due to the new packaging format,
so simply extracting the new archive over the old one will leave
extraneous files around.
To fix this, if we expect to make changes in the `archive.extracted`
state, then completely remove the existing version of the SDK.

Also, unlink the `current` symlink before making changes to an SDK
to avoid processes inadverently using the SDK while it is being changed
(the symlink will be restored once the SDK is done being updated.)

Unfortunately, the `android` tool always returns a 0 exit code even in
case of failure, so this does not yet catch failures.
However, the new `sdkmanager` tool seems to return appropriate exit
codes, so this will kick in in the future.

This will prevent errors from passing silently,
such as bad executable bits or incorrect file permissions.

The Android SDK installation states often have tricky changes
due to upstream changes by Google,
and additionally often fail silently in various different ways
e.g. because the `android` tool always has a zero exit status.
Additionally, some failures are not evident until Servo builds
themselves start failing.

Add a somke test in saltfs to catch common problems early on,
and automatically run it on Travis.

This will clear the entire cache in between runs
when running with SALT_FROM_SCRATCH=false.
Originally, only sls and other files in the state tree were cleared,
but since external modules and other files also need to be cleared,
just clear everything for robustness.

Additionally, move this to after we checkout the new code,
since we sync everything after invalidating the cache,
and we want to sync the new configuration instead of the old one.