Exposing internal memory allocator/free, useful for advance users when required

Pefixing/Suffixing some data type identifier in the variables is not a convention used in raylib, just reviewed it for consistency...

Still, I kept the *Rec suffix in some functions.

Previous implementation did not consider any padding while drawing the characters on screen (despite being available on the font atlas), so, only minimum character area was drawn.

If some text effect shader was required (shadow, glow, outline...), there was no space in the drawn quad to draw that pixels effect.

This commit corrects that issue.

This is a BREAKING CHANGE!

To address the linked issue, several functions have been renamed and couterpart functions have been created to free loaded memory:
 - RENAMED: GetImageData() -> LoadImageColors()
 - RENAMED: GetImagePalette() -> LoadImagePalette()
 - RENAMED: GetWaveData() -> LoadWaveSamples()
 - ADDED: UnloadImageColors()
 - ADDED: UnloadImagePalette()
 - ADDED: UnloadWaveSamples()

Previous GetKeyPressed() method was actually returning unicode codepoints equivalent values instead of the key-code of the pressed key. So, it has been replaced by GetCharPressed(), returning unicode codepoints and GetKeyPressed() now returns key-codes.

* Changed extension for web from .bc to .a

I did this to support vcpkg expectation. When using the library from vcpkg for web you would install it using vcpkg install raylib:wasm32-emscripten but also vcpkg expects the output lib to be with .a extension instead of .bc

Doesn't make a difference for standalone builds or when raylib is used as a subdirectory dependency.

* Added headers to install targets to fix vcpkg usage

Currently vcpkg works by installing the cmake target into its packages directory. The problem is that install only copies the public header at this point so we need to add the others to the install targets.

Since I don't think the purpose of raylib is to save space compressing image, I think it could be a good idea to keep quality from 90 to 100.

Not implemented usage of this variable yet but already setup for the future... some functions require review to consider it on drawing...

Make model collision function call the mesh function.

I did this to support vcpkg expectation. When using the library from vcpkg for web you would install it using vcpkg install raylib:wasm32-emscripten but also vcpkg expects the output lib to be with .a extension instead of .bc

Doesn't make a difference for standalone builds or when raylib is used as a subdirectory dependency.

This change only modifies the default value. In cmake you can have raylib as a subdirectory (dependency) and when you have it as dependency you wouldn't probably want to use the example by default. You can still use the option to enable them though.

* Fixed the build for web using CMake.

I found that the build for me was failing and I added some if defined checks in the core.c file where the glfwSetWindowAttrib was used. (error: implicit declaration of function 'glfwSetWindowAttrib' is invalid in C99 [-Werror,-Wimplicit-function-declaration])

I also changed some values in the toolchain file so that it correctly uses the .bat files when on windows.

* Cleaned up the additional variables (they are not important)

* Added more improvements to cmakelists

Added the option to use the system provided Emscripten toolchain to be more uniform with other libraries.

Fixed and issue which prevented example being built from cmake and also building with html extensions properly.

* Fixed ENUM to STRING because of a missed warning

* Fixed #1455

Fixed writing out of array bounds
Adjusted FPS comment to match value
Deleted unused function at the end, which has never been in use in the history of this file

* Fixed #1455

Readded the function

* Add options to set line width and aliasing to rlGL layer.

* Don't do line smoothing in OpenGLES

1) use the latest windows SDK not a specific one.
2) use the project dir as the root for the include dir for raylib, to help if the project is ever included in some other solution.

WARNING: Some CMake files not changed
WARNING: glfw_native.h contains custom changes

Without GLFW_OPENGL_FORWARD_COMPAT, running this as a standalone will yield the error:
```
NSGL: The targeted version of macOS only supports forward-compatible core profile contexts for OpenGL 3.2 and above
```

Stumbled on this example and I love this! Adding instructions that work for me on MacOS.. Note that glfw3 will need to be statically built locally and copied to this external/libs directory on mac. I can upload my static version, but it probably makes sense to do this only if there's some general naming convention for adding platform specific folders. Like "external_osx/lib" or "external/lib_osx". Then I'll drop my static libs in there.

Let the advance users manage it as they want...