I would have liked config.h to be selected by include dir configuration,
but this way is less intrusive.

That way, a user needs only to touch a single file to configure what
features raylib is built with.
Include guards are left out intentionally, because config.h should only
be included in source files, not headers.

Later on, config.h can also define the raylib version (#461).

Now PLATFORM checks only used on core and utils modules

Renamed SaveImageAs() to ExportImage() for consistency on what actually happens with data.

Not sure if math is ok... just left a commented piece of code that uses pre-multiplied alpha.

Reviewed for PLATFORM_ANDROID and PLATFORM_UWP

This is already the order that is used for Android. It doesn't appear to
make a difference on desktop but on web using the timer before it's been
initialized (by glfwInit, inside InitGraphicsDevice) causes the a long
(and variable but often several seconds) sleep between the first and
second frame.

Fixes: 468309d ("Early-exit InitWindow if InitGraphicsDevice fails")

Changes motivated by commentary in pull request 513

...PLATFORM_ANDROID on Windows, using MinGW-w64 (x86) provided Make (GCC
7.2)

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!

- SetWindowSize() to scale Windows in runtime
- SetMouseScale() to scale mouse input, useful when rendering game to a
RenderTexture2D that will be scaled to Window size (used on rFXGen tool)

GLFW has been updated to latest version, probably this code is not
required any more due to already been integrated into library... but it
needs to be tested...

Renamed function for consistency with a possible Mesh manipulation functions (maybe added in a future). Naming follows Image*() manipulation functions.

It has no sense to be inside LoadOBJ(), mesh processing moved to own functions: MeshTangents() and MeshBinormals(). Not exposed to user yet.

Found by LeakSanitizer in #494.

$ make clean
Makefile:296: *** missing separator.  Stop.

Fixes UB in #489, found by UBSan.

Width specifier doesn't include NUL terminator.
Fixes #487 found by AddressSanitizer.

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

RAYMATH_EXTERN_INLINE was renamed to RAYMATH_HEADER_ONLY, which user code
may define if they want to use it as header-only library. If multiple
files in the same project define RAYMATH_HEADER_ONLY, they might each
have duplicate out-of-line definitions of the same functions.

By default, raymath.h exposes inline definitions, which instructs the
compiler _not_ to generate out-of-line definitons, if out-of-line
definitions are required, those of the file defined with
RAYLIB_IMPLEMENTATION are used instead. There may be only one such file.

In C++ mode, the compiler will select only one out-of-line definition
automatically, so no need to define a RAYLIB_IMPLEMENTATION.

Unfortunately, we have to remove raymath function declaration from
raylib.h as those declarations would lead to duplicate out-of-line
definitions which would yield linker errors. This problem didn't
exist with GNU89 or C++, because there multiple defintions are ok,
but in C99 they aren't.

Besides making it thread-safe, it suppresses a GCC warning
when making them static inline in an upcoming patch.

This reverts commit 6ffc8cb799.
and commit e4d7bbec1e.
which I pushed by mistake...