Master issue for static library nonsense: Windows resource file copying and Unix build oddities

libui needs to be available as both a static and as a dynamic library, as different users have different requirements. Static libraries have two major issues:

- they share the same symbol namespace with whatever they are linked to
- on Windows, static libraries can't have resources

Right now, libui tries to hack around all this by a) obfuscating non-public symbols using a trick deduced by @pcwalton b) manually copying the compiled `resources.o` file on Windows into the `build\out` folder so it can be linked into binaries.

These options have caused nothing but build issues and maintenance nightmares for everyone, including myself, so I'm going to be fixing this properly:

- prefix all non-public names that aren't `static` with `uipriv`
- embed compiled resources on Windows directly into the binary somehow

I need to figure out whether all structs and classes (including ones only used in one source file) need to have this too. All GObject and Objective-C classes also need this change, because they share an application-global namespace regardless.

I need to figure out how to do the Windows resource precompiling thing in a way suitable for each toolchain.