for reference: https://searchfox.org/mozilla-central/source/xpcom/io/nsIFile.idl

the general idea came from onemen and 117649 in the discussion in
https://github.com/xiaoxiaoflood/firefox-scripts/issues/363 but the code
has been written from scratch (as I wasn't convinced of some of their
design decisions). in the end, the overall approach taken looks somewhat
similar, because there seems to be only one way to do that from JS code.

we only rewrite a subset of specified manifest instructions, that are
needed for VimFx. others are passed-through and might make other addons
work. the full list of manifest instructions is documented here:
  https://www.devdoc.net/web/developer.mozilla.org/en-US/Chrome_Registration.html

Further notes on the implementation:

use of constants from (and hence import of) FileUtils has been avoided
by 1) specifying unix file/dir permissions directly instead of using
FileUtils.PERMS_FILE and 2) by relying on default open(2) modes in
FileOutputStream, which are the one we want anyways. its documented at
  https://searchfox.org/mozilla-central/rev/4fd0d5e4669bfa2d0888b730684d8adea061fd30/netwerk/base/nsIFileStreams.idl#96-97

during uninstall(), it does not suffice to re-call .autoRegister() to
remove the chrome.manifest. .checkForNewChrome() has precedence in
mozilla-central:
  https://searchfox.org/mozilla-central/rev/4fd0d5e4669bfa2d0888b730684d8adea061fd30/toolkit/mozapps/extensions/AddonManagerStartup.cpp#770

the file doesn't need to exist in uninstall() at all, and only the
parent directory must exist for install(), but creating it in both cases
simplified the logic a bit. an empty directory will stay behind in the
profile directory after uninstallation - oh, well; too bad.
nsIFile.remove() takes a boolean argument; it determines recursion.
  https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/xpcom/io/nsIFile.idl#272

AddonManagerStartup exposes a method .registerChrome(), which takes a
parsed manifest instead of a file path. This one doesn't support 'skin'
entries (workaround-able with overrides) and does not expose 'content'
entries to the content processes - the latter kills this idea.
  https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/toolkit/mozapps/extensions/AddonManagerStartup.cpp#782
  https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/browser/extensions/formautofill/api.js#124

zipReader code was cribbed from here, with Cc[].createInstance()
replaced by the nicer Components.Constructor call:
  https://searchfox.org/mozilla-central/rev/820596a140570007ce22a6c137ce2520676cfffe/modules/libjar/zipwriter/test/unit/test_alignment.js#73

regressed-by: https://bugzilla.mozilla.org/show_bug.cgi?id=1953136

mozilla calls this 'esm-ification'. the last relevant to us modules were
ported in mozilla124[1], so this is our new minimum version. the old
version will likely be compatible with firefox up to version 128esr[2].

static imports are not supported in autoconfig scripts. i tried to keep
the diff as small as possible w.r.t comm-central's final JSMs. because
of this, we don't lazy-load any modules any more, nor provide any lazy
getters, as they would need to be loaded into a `lazy` object instead
the global (`this`) namespace, causing more churn. other than that, the
largest change was removing the now-useless Services.jsm workaround as
well as removing globalGetters for objects already loaded automatically.

[1]: https://hg.mozilla.org/mozilla-central/rev/68ba071ff6fb9978937496f9adc48e378957f594
[2]: bugzil.la/1881890

not that it is too important. Blocklist.jsm does not export blocklist
state any more. XPIInstall.jsm does this, since way before mozilla61:

  const { nsIBlocklistService } = Ci;
  addon.softDisabled = addon.blocklistState == nsIBlocklistService.STATE_SOFTBLOCKED;

c.f. https://searchfox.org/mozilla-central/rev/b503616295d69fee56300e5e2093599e6fb4f0e2/toolkit/mozapps/extensions/internal/XPIInstall.jsm#531

minimizes the diff we need to keep. note that as previously mentioned
this requires mozilla>=85, but shouldn't cause issues unless called.

This partially reverts commit 553416c2d6d3c760cf98bd2c4afbaf0442321951.

osfile.jsm was removed by bugzil.la/1772262. This method is not used any
more, so we can just remove it. the modern alternative would be the
following, but that only works on mozilla>=85.
    return IOUtils.writeUTF8(file, this.serializeToString());

osfile.jsm was loaded lazily (and in our case therefore never), so we
didn't die immediately upon import, fortunately.

see also: https://hg.mozilla.org/mozilla-central/diff/a11c616997d802e44d1afc0215bfbffac865179e/toolkit/components/passwordmgr/test/LoginTestUtils.jsm

console.createInstance() is available since firefox59 (Bug 1425574), so
no workaround needed. ChromeUtils.defineLazyGetter() however only is
since firefox112 (Bug 1805288) but the backwards-compatible code is tiny

see also:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1875216
  https://bugzilla.mozilla.org/show_bug.cgi?id=1430810
  https://bugzilla.mozilla.org/show_bug.cgi?id=1828156
  https://groups.google.com/a/mozilla.org/g/dev-platform/c/BdyWnTjLSXg

makes LegacyFox compatible with Firefox 117.

regressed-by: https://bugzilla.mozilla.org/show_bug.cgi?id=1780695
see-also: https://hg.mozilla.org/mozilla-central/rev/911d540fce6f

reported to https://github.com/xiaoxiaoflood/firefox-scripts/issues/115

> I just found that for my legacy addon after restart it some of it
> function calls that initiated by timer or observer callback are
> running in a sandbox context of the last startup which is different
> from current one. And this cause malfunctions for my addon.

see also: https://github.com/xiaoxiaoflood/firefox-scripts/commit/291bebc4f2edc919dd273f2cecbbfda61e157695