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

hg.mozilla.org now redirects to hg-edge.mozilla.org.

this also removes the reference to the long obsolete
https://hg.mozilla.org/mozilla-central/rev/061b97e02ede.

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

The wildcard will match both /usr/lib and /usr/lib64, so the Makefile
works on 99% of Linux distros. And yes, that's not what DESTDIR is for.

this hopefully makes the monkey patch update persistent.

Note: instead of using FileUtils, this would be another method:
  const {Services} = Cu.import('resource://gre/modules/Services.jsm');
  let manifest = Services.dirsvc.get('GreD', Ci.nsIFile);
  manifest.append('legacy.manifest');

still has the mozillapath hardcoded, though