Expose chrome.runtime.inIncognitoContext

[tophf]

Supersedes #605 with a different solution and an explanation why workarounds are problematic.

Goal: expose chrome.runtime.inIncognitoContext in all contexts.

Optional goal: deprecate chrome.extension.inIncognitoContext

• We'll fix the false implication that the [entire] extension is in the incognito context - compare it to the other methods in the extension namespace that apply to the entire extension conceptually e.g. isAllowedIncognitoAccess, isAllowedFileSchemeAccess, getBackgroundPage, getViews.
• We'll continue the established trend: lastError, getURL, sendRequest/sendMessage, onRequest/onMessage

Immediately beneficial use case: userscripts of extensions in the default spanning incognito mode.

The problem doesn't concern the split mode extensions which can embed the value in the code of the userscripts registered just for the incognito mode.

The workaround for a userscript is problematic as it requires an additional "isolated world":

• it consumes a lot of memory (more than 40kB) and time to initialize the entire JS world compared to this simple boolean value, which translates into multiple megabytes and seconds for users who have a lot of tabs and consequently frames;
• it's not necessary for other functions of the userscript extensions e.g. Violentmonkey only uses messaging to handle everything in the background script including storage access and its propagation to other tabs, because the built-in chrome.storage is too slow in Chrome and inflexible everywhere as there's no way to register the onChanged listener for specified keys, but even if there was an extension may prefer IndexedDB for its richer API;
• it cannot be created synchronously on demand, so extensions can't use a lazy getter;
• it cannot be destroyed to reclaim the memory.

[oliverdunk]

I spoke to @rdcronin about this. We are supportive of adding this property to chrome.runtime and exposing it to user scripts. As mentioned in the original post, the property on chrome.extension would be deprecated but remain around for backwards compatibility.

We both agreed this probably doesn't need to be configurable using userScripts.configureWorld. Let us know if you feel otherwise though, @tophf.