From the Clang documentation[1]:
> -x<language>, --language <arg>, --language=<arg>
> Treat subsequent input files as having type <language>

Follow the advice. Fixes #840.
[1]: https://clang.llvm.org/docs/ClangCommandLineReference.html

This reverts #841 commit 97160fd970.

Some minor tweaks

Found some issues when building for web using latest emscripten 1.38.30, traced the error and found that eglGetProcAdress does not return function pointers for VAO functionality, supported by extension.

It requires more investigation but now it works (avoiding VAO usage)

The idea is supporting additional raygui and physac modules building with raylib but those modules are distributed as header-only libraries and it makes a bit dificult to build them inside raylib...

Renamed flags for convenience.

Planning to promote raudio module as a simple and easy-to-use front-end for the amazing mini_al library, so the name change.

Name comes from raylib-audio but in spanish it also remembers to word "raudo", meaning  "very fast", an analogy that fits perfectly to the usefulness and performance of the library!

Consequently, raylib version has been bumped to 2.4-dev.

Solves audio cracking issues

Added android_native_app_glue module to raylib compilation instead of
compiling it as static lib at apk generation.

From 2019 64bit support will be mandatory to publish an Android app.
Google plans to require that new apps target Oreo (API level 26) in
August of 2018.

Please do this whenever necessary. And adapt it before releasing a new
RC. The RC should already have the correct one.

Now defaults to Clang, ARM64 and API 21

Review raylib_icon resource

...PLATFORM_ANDROID on Windows, using MinGW-w64 (x86) provided Make (GCC
7.2)

$ make clean
Makefile:296: *** missing separator.  Stop.

jar_xm.h does some shady pointer casts leading to unaligned accesses
and breaking strict aliasing. x86 has special circuitry for doing
unaligned accesses, but on other architectures, it may trap and require
kernel fix-up or crash outright. With this patch, one obstacle in
porting raylib to the GameBoy Advance has been removed. Go for it ;-)

To avoid having to rewrite that `mempool' code, insert padding before
structs and instruct the compiler (GCC, most importantly), to be gentle
when optimizing.

This fixes #490 (Unless we got ourselves 256-bit pointers, if so,
hello future!)