Did this ever work? Surely, doesn't look like it...

I don't know if this actually works, but it compiles, which is good enough for CI.

src/core.c does explicitly skip including <camera.h> on Android
and tests fail. Therefore skip these failing tests.

Closes #507.

Not sure if this ever worked, but now it at least compiles.

Release, unless we are in a Git repo, then it's Debug.

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.

On OpenGL 1.1 only is supported for 32bit RGBA textures

Increase API version

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

This reverts commit 2d6fb5c628068757387525e190c3afdbe33ae9c6,
and adds a fix for Alien::raylib's test failures.

The tests failed because the resulting static library didn't reexport
GLFW symbols. As a fix, we now have GLFW create a CMake "object library"
target that we can link with both the static and shared raylib.

This is arguably ugly... Proper fix would probably be a GLFW upstream
object library target.

Closes #536.

Makefile: Remove unnecessary -no-pie for older GCC support

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.

This reverts commit 0adb4b67de6dfe3f7a0a557130dffc3b8f4d6a43,
because it failed tests for Alien::raylib:
http://www.cpantesters.org/distro/A/Alien-raylib.html

Review raylib_icon resource

CMake+CI: Add Wayland configuration

Makes it easier to support Wayland later on.

We need the CMake stuff for wayland configuration.
Otherwise, we would have to replicate that ourselves.
This is the full 7ef34eb06d tree except
for tests/ examples/ and docs/

Panders to the idiosyncrasies of my work flow:
I have my raylib build directory mounted as a VirtualBox vboxfs for use
with my Linux VM, but vboxfs doesn't support symlinks, while raylib shared
library versioning on Unix expects symlinks to work.
If this happens, library versioning is now disabled on Unix with
an error message instead of just failing the build.

Patch implicit type

Try to avoid types conflict with Font

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