Fix Crystal::Target#unix? to consider android

[straight-shoota]

aarch64-linux-android currently gets the unix flag, because of linux. But the alias aarch64-android does not contain linux...

[ysbaddaden]

I think we ought to fix <arch>-android.* to be <arch>-linux-android.* instead.

[straight-shoota]

We usually leave normalization to LLVM.normalize_triple. And apparently, it considers ``${arch}-linux-androidand${arch}-android` as different targets.
I'm not sure if we should still override that, although it seems reasonable to not have two different canonical android targets.
However, the question still remains, which form should we consider as canonical 🤷

This PR is just a simple fix to make the aarch64-android target work. This is necessary to make automated tests that read target triples from src/lib_c/ work.

[HertzDevil]

LLVM sees android as an environment name, i.e. the fourth component of a triple, in the same category as gnu or musl, rather than an OS name. So it is more appropriate to move or symlink src/lib_c/aarch64-android to src/lib_c/aarch64-linux-android (and Crystal::Codegen::Target#os_name doesn't need a special case for Android), since those directory names are supposed to be canonical LLVM triples without the vendor component.

[straight-shoota]

Yes, we can fix this particular problem from the other end as well 👍

That moves aarch64-android out of the spotlight, but still keeps open whether we should normalize it.

[straight-shoota]

Superseded by #16409

[straight-shoota]

Oh, but Target#os_name considers android as a separate operating sytems.
Thus, CrystalPath#add_target_path(codegen_target) normalizes to aarch64-android.

[ysbaddaden]

It's an error IMO. It shall return linux-android and that would work, as long as we add an android -> linux-android symlink for older compilers.