This commit adds api_window_close and api_browser_close, removes the
__gc entry entirely for those types, and adds the CLOSEBROWSER_OSR ipc
message. Allowing EmbeddedWindows to be closed without the whole plugin
was a significant rework, so there may still be some edge-cases.
A much cleaner way of sending host-to-client messages compared to that
byte hackery I was doing before. Also probably runs faster because of
larger reads/writes instead of smaller individual ones for each param.
Every edge-case should now be accounted for: closing an embedded
browser, closing a game client, closing a plugin from the host, closing
a plugin from the client.
Plugin library no longer receives plugin ID at all, only an ID specific
to this activation of the plugin. This solves race conditions where a
plugin is restarted while an IPC message relating to it is mid-flight.
So it turns out Windows supports AF_UNIX sockets via the afunix.h
header, as a somewhat drop-in solution for IPC. Some messing around was
required to get it to compile against winsock functions and Ws2_32.lib,
and it still doesn't actually do anything, but the IPC portion seems to
be working perfectly.
Due to a Lua ""feature"", light userdatas all share the same metatable,
so setting individual ones for each event wasn't working very well. The
solution instead is to replace the light userdata pointer with a full
userdata with the event struct copied into it. This also means we can't
have window objects being presented in callbacks, but that's okay, I
think plugins should be using upvalues for that anyway.
Calculating strlen of a hard-coded stringat runtime, by iterating
through it until finding a 0 byte, is nothing but a waste of CPU cycles.
We already know the length, so let's just use it directly.
It's more resource-intensive, but all the plugins sharing one stack was
causing so many problems that I'm not sure it was even possible to do
correctly; Lua stacks are aggressively global, and all the plugins
sharing one set of global state was causing so many bugs, not to mention
safety issues of plugins potentially having access to each other, that
it's simply not worth the trouble.
