* Normal vbo not correctly updated

Uses fewer vertexes than using DrawCube() or DrawSphere() for points.  The small line is on analogy to the code for DrawPoint() in shapes.c.

* explained a bit more the core_window_letterbox example

* fixed a few 'ups' moments that could lead to mild head pain and time loss

* Initial commit of addition for GLTF materials.. should support loading more than just albedo map.

* Clean up

* fixed seg faults and leaks

* temp don't overwrite defuse colour when rendering

* undid something dumb!

* correctly mixed diffuse map color when rendering to preserve not overwrite it

All data should be properly initialized by now

- Mesh, Shader, Material structs have been reviewed to minimize size when passed by value, all required code has been reviewed.
 - GetCollisionRayModel() reviewed to avoid pointer, not required because model is not modified inside the function
 - UnloadMesh() reviewed, pointer not required
 - CheckCollisionRay*() parameters name reviewed

Free texturePath in LoadGLTF()

* Fix loading multiple animations from .iqm file

* Fix memory leak in models_animation example

* Added export instructions to the animation example

* use raylib free

* include <stdlib.h> to appease the travis CI gods

* replace tabs with spaces

* 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

Added comments for the future

Note that all meshes are loaded as a single one at this moment, loading should be improved!

Square root calls are computationally expensive.  In this case, they can be avoided.  Instead of checking distance<RadA+RadB, check distance squared against (RadA+RadB) squared.  The dot product of Vector3Subtract(B,A) with itself gives distance squared, so I used this code instead of an element-by-element computation of distance squared.  The only downside is that your geometric code is very readable, whereas this is less so.

Users can define their custom memory management macros.

NOTE: Most external libraries support custom macros in the same way, raylib should redefine those macros to raylib ones, to unify custom memory loading. That redefinition is only implemented as example for stb_image.h in [textures] module.