To generate 2D polygonal shape

This commit implements a big update of rlgl module, intended to optimize some parts. This change could break some code bases... hopefully not, but it could.
The BIG changes to the module are:
 - Replaced LINES-TRIANGLES-QUADS buffers by a single one, now all vertex data is accumulated on a single buffer and managed with registered draw calls. LINES-TRIANGLES-QUADS could be used the same way as before, rlgl will manage them carefully. That's a big improvement of the system.
 - Support multi-buffering if required. Just define MAX_BATCH_BUFFERING desired size (currently set to 1 batch). Should be enough for most of the situations.
 - Removed temporal accumulative buffers for matrix transformations, now transformations are directly applied to vertex when on rlVertex3f()
 - Reviewed rlPushMatrix()/rlPopMatrix() to be consistent with OpenGL 1.1, probably I should remove that ancient behaviour but... well, it was not consistent and now it is.
 - Minor tweaks: LoadText(), I broke it in last update... also multiple comments reviewed.
 - TODO: MAX_BATCH_ELEMENTS checking should probably be reviewed... done some tests and it works but...

Fixes: c3b948b1 ("Replaced skybox HDR image")

Replaced old dwarf model

Note that HDR exposured possibilities are not used on this example...

Replaced by medieval 3d assets

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

- Added Vector3OrthoNormalize() to raymath.h - not sure if it is correct
- Implemented MeshBinormals() - Mesh struct has not a place for them...
- Updated model_material_pbr example - tested but not working on my GPU
(old Intel HD), actually, it never worked on it...

Changes made based on commentary in pull request 513

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.

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.

Could correct possible issues on OpenGL 1.1

...and reviewed some details

SetMaterialTexture() and UnsetMaterialTexture()... too shader
dependant...

Moved PBR material loading to example, right decision?