Examples can be compiled for web with no code change at all! Usually
examples need to be refactored for web... using emscripten code
interpreter (emterpreter), it can manage synchronous while() loops
internally... as a downside, execution is very slow...

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

- 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

Support external GLFW usage
Renamed some flags for consistency

Updated to latest GLFW library and working on Wayland support, still
looking how to implement it on raylib because it just exposes
PLATFORM_DESKTOP and defaults to X11 windowing system on Linux...

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...

libEGL and libGLESv2 have been renamed on latest Raspbian Stretch
version (also included on latest Jessie upgrade).

It seems to be done to avoid conflicts between official Mesa libs and
Broadcomm provided ones.

- Review RPI compilation (core_drop_files not supported)
- Review ImageFormat(), some issues
- GetTextureData() reviewed for RPI

...and reviewed some details

Some people might find this handly

...to avoid issue on Arch Linux

We need to grab the OS name before determining what the path should be.