Implement autodetection for default compiler from NDK

[Dushistov]

ref #459

Long time ago you had to extract compiler from Android NDK to make it standalone and usable as linker/c/c++ compiler (for example process described here https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html).

At now you can use default C/C++ compiler without efforts. But naming for compilers are different now. For example before this patch, cc-rs try to find arm-linux-androideabi-clang, but default compiler now is armv7a-linux-androideabi16-clang. Also new clang compiler doesn't define things like ANDROID/__ANDROID_API__ so it should be defined manually.

Without this patch I can not compile rusqlite for android:

//Cargo.toml
[dependencies]
rusqlite = { version = "0.17.0", features = ["chrono", "functions", "bundled"] }
//.cargo/config
[target.armv7-linux-androideabi]
linker = "armv7a-linux-androideabi16-clang"

it prints:

error occurred: Failed to find tool. Is `arm-linux-androideabi-clang` installed?

[alexcrichton]

FWIW this normalization isn't used when trying to find a new compiler, could this be refactored a bit such that these rustc targets would still find the armv7a android compiler?

[Dushistov]

I intentionally did not touch this code. Tier 1,2 platforms have only linux+android support. So it is hard test for Windows and MacOS, but code bellow works with windows, so I avoid changing anything that I can not test.

Plus I don't think that this is refactoring is possible. IMHO new target naming that include android API level was introduced recently, so if somebody do not want update Android NDK and uses old clang it is easy enough to break things for them.

[alexcrichton]

My point is that the armv7-linux-androideabi target, if folks are using it, will not hit the new clang compiler when it very likely should. I don't think there's a lot of risk here, it's basically just moving this let target block up to the top of the function instead of having it at the bottom

[Dushistov]

My point is that the armv7-linux-androideabi target, if folks are using it, will not hit the new
clang compiler when it very likely should.

@alexcrichton, not sure that I understand you. armv7-linux-androideabi mapped to Some("armv7a") and then to armv7a-linux-androideabi16-clang call.
So armv7-linux-androideabi hit the new clang compiler, it is my main testing configuration,
I built all my code with cargo build --target=armv7-linux-androideabi and ran on android device before submitting this PR.

[alexcrichton]

Ah ok I think I was misreading a bit. In any case we can always tweak this later!

[alexcrichton]

Thanks again!