* Make raymath naming and functions more consistent

* Minor fixes

* Fix examples

* Fix Physac

* New naming rules

* Apply naming to Quaternion functions

* Apply to models.c

* Remove *MulitplyValue / *DivideValue

* Update raymath.h

Added Vector2Rotate Function.

* Update raymath.h

Just for clarification, no plans to remove libc dependency, just did some code analysis to see how much raylib depend on stardard C library. My conclusions:

 - stdlib.h: primary dependency is for malloc() and free()
 - stdio.h: primary dependency is for FILE access, maybe it could go through a custom ABI?
 - string.h: just around 8 functions required
 - math.h: just around 8 functions required
 - others: 1-2 functions required for some other headers

Renamed for consistency with Vecto2Scale()
Also renamed Vector3MultiplyV() to Vector3Multiply()

* Update year of copyright notices

* Fix mistake in comment

* Fix typo ("algorythms")

* Replace tabs with spaces

* Remove trailing whitespace and fix mistake in comment

* Fix ExportImageAsCode missing comment rectangle corner

* Replace tab with spaces

* Replace tabs with spaces

Removed a useless semicolon.

- Added Vector2MultiplyV
- Added Vector2DivideV
- Added Vector3Divide
- Added Vector3DivideV

- Using raylib.h as reference, added define checks for BUILD_LIBTYPE_SHARED and USE_LIBTYPE_SHARED.

- Added check for dllexport to compile if _WIN32 defined.
- If not defined then use the original RMDEF.

- Added __declspec(dllexport) to RMDEF in raymath.h. This allows them to be accessed when importing from raylib.dll.

Rotate a Vector3 by a Quaternion

Replaced by fabs() that seem to work ok

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

Reported in #435, tcc generates out-of-line definitions for inline
symbols, something it shouldn't.  This fix punishes tcc for that
by making applications it compiles (slightly) larger...

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.

To multiply Vector3 by Vector3

For consistency!

Some other tweaks...

Now it should be coherent with OpenGL math standards

Exposed some raymath useful functions to raylib API

Consistent with similar functions in raymath