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!)

These changes are intended to provide context and control over the Linux make install process. make install RAYLIB_LIBTYPE=SHARED now works as expected. libraylib.so is properly installed with attendant runtime links. The examples will be running against the newly installed libraylib.so unless otherwise specified with RAYLIB_RUNTIME_PATH. See raylib/src/Makefile and raylib/examples/Makefile for usage of RAYLIB_INSTALL_PATH, RAYLIB_H_INSTALL_PATH, and RAYLIB_RUNTIME_PATH variables. RAYLIB_RUNTIME_PATH in particular is interesting for portability since sudo isn't needed.
The default configuration and workflow is essentially unchanged and unaffected.

which is the default behavior on C99 and up.