Now it's required on Windows if not using a busy wait loop

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)

Support file download to disk from memory filesystem.

raylib resource data file for Windows platform (containing raylib icon and metadata for executable file) has been renamed to a more consistent name: raylib.rc.data

Also required to work with tcc compiler.

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.

Currently, if:
* GCC doesn't supports -no-pie: Build error
* GCC supports -no-pie
    * GCC is not configured with --enable-default-pie: No-op
    * GCC is configured with --enable-default-pie:
            Slightly worse performance because we still generate -fpie code
            (-pie affects linker, -fpie affects compiler)

So instead of probing for existence of -fno-pie -no-pie, remove it altogether.

Fixes #540: Build breakage on Debian 8 with gcc 4.9.

Review raylib_icon resource

- Preparing MP3 files support
- Jumped version to raylib 2.0-dev (too many breaking changes...)

Removed OpenAL and GLFW3 dependencies on building.
Reviewed platforms and flags

Inspired by #504.
Instead of requiring the user to do PLATFORM_ANDROID #ifdefery,
have the android_main entry point exported by raylib and call
the user-defined main. This way many games could (in theory)
run unmodified on Android and elsewhere.

This is untested!

- Renamed VERSION to RAYLIB_VERSION
- Renamed API_VERSION to RAYLIB_API_VERSION
- Renamed RAYLIB_RELEASE to RAYLIB_RELEASE_PATH
- Support Web Assembly compilation on PLATFORM_WEB

OpenAL Soft backend is still available in audio module, I'm thinking if
exposing it for building in some way or just left it there for advance
users to switch to it manually in case of necessity...

It seems there are some platform-dependant issues

- Removed useless templates
- Reviewed all Makefiles
- Rework some code for Android support
- Added resources to advance template

Notice that requries libraries are directly taken from
raylib/release/libs/android folder and nativeLoader.java is generated by
Makefile on the go

Using shared libraries just don't work...