As noted in #539, the symlink check was to support compiling raylib on
VirtualBox vboxfs as no symlinks are supported there.

With me using Linux as daily driver outside VirtualBox now, this 'feature'
is most likely unused by anyone, but still annoys other users (#791).
Just revert it and be done with it. If there are really others building
raylib on vboxfs or a similarly crippled file system under Linux, they
should now step forward when their build breaks.

This reverts commit b8ca51fd01.

This reverts commit 23c1c0bdb2.

Because add_if_flag_compiles apparently allows unsequenced
even if the compiler doesn't support it..

They not only result in discrepancies between different compiler,
but trigger undefined behavior. Avoid them by having them break
the CMake build and CI.

Remove that link_libraries_to_executable() hack and defines a proper
raylib target that can be used with target_link_libraries.

The same target is also available for external (user) code by using
find_package(raylib).

This results in:

- Remove hardcoded build directories from examples and games CMakeLists.txt
- Allow rlgl_standalone and other special examples to be built easily
- Allow CMake projects to find_package(raylib instead of fiddling with pkg-config
- Makes code a little more maintainable
- Fixes #471, #606.
- Makes code less confusing by removing the double use of PLATFORM (#584).

Note that this is still not _The Right Way_(TM), because normally
raylib-config.cmake (or its includes) would be automatically generated.
I didn't manage to get that to work though, so I went the easier route
of just wrapping pkg_check_modules for consumption by find_package.

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.

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

To make bugs like #485, #486, #487 and #488 easier to find in future.

which is the default behavior on C99 and up.

As an extension, GNU C treats sizeof(void) as 1. MSVC doesn't.
Make it an error on GCC/Clang to avoid accidental MSVC breakage.

Otherwise using a compiler that defaults to -std=c89 or -std=gnu89 will
fail. Example:
http://www.cpantesters.org/cpan/report/abb85066-d283-11e7-9926-b2f4efb9c382

Apparently, -m32 Travis CI build was broken: -m32 was overridden by
-std=gnu99.  This fixes that.

Some people might find this handly