Add setting for "fallback to iframe jailing only" functionality, and timeout value

[Venryx]

The file lib/_frame.js contains this code:

    // mixed content warning in Chrome silently skips worker
    // initialization without exception, handling this with timeout
    var fallbackTimeout = setTimeout(function() {
        worker.terminate();
        initIframePlugin();
    }, 300);

    // forwarding messages between the worker and parent window
    worker.addEventListener('message', function(m) {
        if (m.data.type == 'initialized') {
            clearTimeout(fallbackTimeout);
        }
        [...]
    });

So it tries to run the user-script in a web-worker (within the sandboxed iframe), and if it fails (ie. if "initialized" message is not received within 300ms), then it tries again without the web-worker jail layer.

That's understandable. However, it would be nice if the library let you choose whether to:

1. Try to use iframe+web-worker, but fallback to iframe-only if web-worker fails. (current functionality)
2. Try to use iframe+web-worker, and throw error if web-worker fails.
3. Always only use iframe.

Furthermore, it would be nice if one could customize the timeout-length for determining if the web-worker layer failed. Why?

Because the default value of 300ms is too small sometimes! When I ran user-scripts within jailed five times, it worked as expected four times (with the web-worker layer initializing within the 300ms), but one of the five times, it took too long for the web-worker to initialize, and so jailed got rid of the web-worker layer (despite the context in fact supporting web-workers, as seen from the non-fallback-activated calls).

This means that:

1. The web-worker security layer was avoided for one of the calls, despite this not being necessary. (This makes usage unpredictable. For example, it changed an error from ReferenceError: alert is not defined to VM4703:4 Ignored call to 'alert()'. The document is sandboxed, and the 'allow-modals' keyword is not set., which then failed to show up in my regular error-catching-and-displaying system.)
2. In rare cases, it's possible this could result in a user-script partially-running more than once. (if there is a slight delay in the "initialized" message being received, that tells the main process to cancel the fallback timer)

Anyway, these issue would be resolved by adding a setting for the three fallback functionalities above, as well as a setting to customize the fallback-timer duration.