...and MacOSX OBJC types definition...

Expose native Cocoa Window again...

This implementation is a bit limited, does not support wide characters directories but it's a temporal solution...

This solution uses "io.h" (like MinGW provided one) while other modern solutions use the "windows.h", that result in duplicate symbols issues... need to review it carefully.

Could not be retrieved for now...

Not supported for the moment, issues with Linux (symbol `Font` redefined) and OSX (NSGL type redefined)

REVIEW: Reorganized global variables for consistency
ADDED: GetWindowHandle() to get native window handle
ADDED: GetDirectoryFiles() to get files list for a DIR

-DBUILD_SHARED_LIBS=OFF == -DSHARED=OFF -DSTATIC=ON
-DBUILD_SHARED_LIBS=ON  == -DSHARED=ON  -DSTATIC=OFF

Fixes #626.

Apple ought to fix their OpenGL implementation, but with OpenGL now
deprecated this might not happen.

This has been reported upstream in GLFW in glfw/glfw#1334.
The workaround comes from kovidgoyal/kitty@b82e74f99

This also fixes the HiDPI (Retina) scaling issues reported in #497,
so the workaround is enabled anywhere __APPLE__ is defined.

Previously, if <raylib.h> was #included prior to another header that
defined bool, the compilation would fail.
This is e.g. the case for <perl.h> and <objc/objc.h> which both fall
back to the <stdbool.h> if C99 is available.

The following commit includes <objc/objc.h> in src/core.c, which causes
the same problem.

Avoid this by checking for C99 bool like we already do for C++'s.

A single warning at configuration time is enough.

[textures] Added SaveKTX()
[rlgl] Exposed rlGetGlTextureFormats()

- Using same idea as SetWindowMonitor to take in a index with 0 being the primary monitor.

- Added else so return not compiled twice.

- Added PLATFORM_DESKTOP check for Monitor functions to try to fix issue on android.
- Not sure what return types should be when not on desktop. Added rough guess for now.

- Fixed tabs used instead of 4 spaces

- Get number of monitors
- Get size, physical size and name of primary monitor. Could pass monitor id instead not sure.

Added note on KTX 2.2

REVIEWED: ExportImage()
REVIEWED: ExportMesh()
ADDED: ExportWave()
REMOVED: Internal funcs: SavePNG(), SaveBMP()

NOTE: These changes break the API (parameters order)

Some minor tweaks around

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

fix bug with GenMeshPlane() creating too many vertices/texcoords/normals for the plane mesh

Useful for bitmaps pixelated fonts where anti-aliasing is not desired!
Change also enables additional font generation mechanisms in a future (cleartype, hinting...).

strprbrk() does not follow raylib function name convention but as it is
very similar to the standard strpbrk(), we'll keep the naming... also,
don't like to mix static functions with API functions but as strprbrk()
is just used in the two functions below, it's ok to be there... maybe it
could be refactored in a future or even move the logic inside the
required functions...

Noted in #634.

Fixes #634.

When a batch reach its vertex limit, a draw call is issued and batch restarted for refilling but if the draw call was issued for vertex data accumulated inside rlPushMatrix/rlPopMatrix, draw call was issued before the rlPopMatrix, consequently modelview matrix was not properly recovered before the draw call... obviously, it only happened the following draw calls, not the first one...

Now it works ok but this system needs to reviewed, noticed and important frames drop when processing around 20 dynamic batch draw calls, it means filling MAX_QUADS_BATCH (8192) quads of data 20 times per frame, including data updating and sending for draw processing.

Doing some maths, it means:
Vertex data (float) -----> 8192 quads * 4 vertex * 3 comp * 4 byte = 393216 bytes
Texcoords data (float) -> 8192 quads * 4 vertex * 2 comp * 4 byte = 262144 bytes
Color data (uchar) -----> 8192 quads * 4 vertex * 4 comp * 1 byte = 131072 bytes

Thats a total of 786432 bytes (0.75MB) sent to GPU 20 times per frame for processing... I'm testing in an Intel HD Graphics integrated, I imagine is too much data to be sent and and it causes stalls, so the frames drop...

Corrected memory leak!