Add Embeddable/None platform targets

[IoIxD]

This PR adds two new platform targets: PLATFORM_EMBEDDABLE, and PLATFORM_NONE. Alongside these, it puts parts of rcore.c into a new "rcore.h" file, which also includes GetCore, a function that returns CORE.

Both platform targets are blank slates. All of the functions within them have appropriate function pointers which can be left NULL or be overriden at runtime. The difference between the two is that Embeddable links against glfw by default, while also giving certain functions that don't explicitly rely on glfw (such as setting the window state or setting the cursor's state to be hidden) default behaviors. None does not do this.

They both represent two use cases, one important, and the other interesting.

• Embeddable: Intended for embedding Raylib into other GUI libraries without having to fork the code. This actually started as me wanting to place Raylib in a GTK application, only to find out that the library that lets me do this relies on a fork of Raylib 3.7. By not having to fork the code, these kinds of libraries get a level of future proofing, as they can override functions that are potentially the same in a future version and potentially work with later versions of Raylib.
  GetCore is a bit of a risky function to both use and implement, as it'll very likely prove to have a more unstable API then others. But I think that even with this fact it'll still be useful, because even if things break, they can still (hopefully) be easily updated, even by somebody who didn't work on the library, all in a fashion that's much easier/nicer then one having to fork the entire Raylib codebase.
  It's not the most pretty to use or maintain (just see the new core/core_override example that's provided, I think would be the first feature of Raylib that requires a union to be used, for reasons out of my control), but it does solve a legitimate use case. This actually started out as me trying to add a InitOffscreenWindow function, but what I realized is that this would be trickier to implement, and I like doing this better because:
• None: This enables of a level of protection for ports of Raylib to obscure/old platforms. The reasoning here is essentially the same as the sentence I just wrote: Instead of having to completely fork the Raylib codebase for something that might have pretty low priority to them, their library can override the functions at runtime and potentially be future proofed. It's also just good if somebody wants to embed Raylib but doesn't want the default behaviors.

Lastly, there is a downside that I think may affect CI: The macros used to make this cleaner to implement, don't seem to work when using GNU Make. I don't know if this a problem localized to my machine or if it'll affect this, or even why it happens when I'm pretty sure I only did stuff that was standard, but we'll see.

[IoIxD]

Rejected in the Discord