Main loop scheduling

Two changes:
  - Fixes a bug where calling `emscripten_set_main_loop` with fps=0 in a sequence with `emscripten_cancel_main_loop` would not properly cancel the previous loops, but the rAF timers would stack up, calling the main tick function at a too fast rate.
  - Adds support for controlling swap interval as an Emscripten-native API, and in EGL, GLFW and SDL.
I am not at all fond of breaking practically _all_ existing code that everyone is building. In the current form, one can do

    emscripten_set_main_loop(callback, fps, 0);

for continuing to use the old behavior, or

    emscripten_set_main_loop(callback, anyValue, 0);
    emscripten_set_main_loop_interval(interval);

to use the new api. Also, like shown in the demo, the new `emscripten_set_main_loop_interval` api can be used without resetting the main loop, so one can do

    emscripten_set_main_loop(callback, 0, 0);
    ...
    void onSomeUserInput() {
        emscripten_set_main_loop_interval(newInterval);
        // or using one of EGL, SDL, GLFW or others:
        // eglSwapInterval(newInterval);
    }

to set the new swap interval. For example as a response to detecting that the game can't run steadily at 60fps but it should revert to 30fps, it might detect that it is seeing too much variance in the rAF times, and switch to one lower swap interval to get less stutter. That kind of schemes would be more clumsy if one had to first cancel the main loop, and then restart it again with the new settings, and one would possibly have to pass the previous `callback` pointer around in object-oriented environments.

Having a `emscripten_set_main_loop(callback, fps, swap_interval, as_fast_as_possible);` also has a large redundancy to the parameters and there are several invalid combinations: i.e. if I set `fps=150`, what would it mean if I also set `swap_interval=2` and `as_fast_as_possible=true`? That would lead to overlap, because these timing mechanisms are mutually disjoint.