Added support form vertical and horizontal 3-patches.
Corrected the distortion caused when destRec size is smaller than 4x4. Now even 1x10 or 0x0 sizes are drawn correctly.

Added NinePatch struc definition and function prototype.

Still a work in progress but it already works...
Current riqm API could be simplified...

Vector4 -> Quaternion
Texture2D -> Texture
RenderTexture2D -> RenderTexture
Camera3D -> Camera
SpriteFont -> Font

Note for me: Replace All is NOT your friend...

Library consistency rename... yes, I know, it breaks the API...

Added: data to CharInfo struct
Added: LoadFontData()
Added: GenImageFontAtlas()
Removed: LoadFontEx()
Removed: LoadTTF() [internal]
Some code tweaks

Reviewed: GetImageData()
Reviewed: ImageFormat()

Added note idea on ImageFormat() for future redesign (to support
16bit-32bit pixel-formats)

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

- Renamed Begin3dMode() --> BeginMode3D()
- Renamed Begin2dMode() --> BeginMode2D()
- Renamed End3dMode() --> EndMode3D()
- Renamed End2dMode() --> EndMode2D()

- Some examples tweaks
- Reviewed ImageFormat()
- Use float for text fontSize

Useful to parse raylib.h to generate raylib-lua and Notepad++
intellisense XML info

Just added a fallback in the meantime...

Added raylib version to config

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

Reviewed for PLATFORM_ANDROID and PLATFORM_UWP

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

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

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

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.