Revert "automatically disable signature requirement"

downgrading the warning color stopped working some time ago. for
completeness, as of nightly99 xpinstall.signatures.required is only
checked in these places, none of which affect us:
- nsContentSecurityUtils.cpp::DetectJsHacks()
  only for telemetry and relaxing some security measures we don't need
- BrowserGlue.jsm::_onWindowsRestored()
  gates call to _notifyUnsignedAddonsDisabled(), which isn't triggered
  by our stuff (signedState != SIGNEDSTATE_MISSING)
- AddonSettings.jsm::REQUIRE_SIGNING
  overridden by our config.js script, so doesn't matter
- XPIProvider.jsm::observe()
  calls XPIDatabase.updateAddonAppDisabledStates(), which calls
  this.updateAddonDisabledState(addon), which depends on
  this.isUsableAddon(aAddon), which returns true as long as we override
  this.isDisabledLegacy(aAddon)

This reverts commit 29dc0ab3a8f8bd6e781fb983cd076764480dce18.

remove EXPERIMENTS_ENABLED override

this was never required.

Revert "Enable Webextension experiments"

This reverts commit 152b73585cf37a64b8022c8bd027587c9d9e511f.

Enable Webextension experiments

This is outside the scope of LegacyFox and will be reverted. Only barely
tested.

automatically disable signature requirement

Having signatures enforced causes a big red error message to appear
below unsigned extensions, telling the user the extension has been
disabled. This is not true, though; the extensions are still enabled.
Setting xpinstall.signatures.required;false downgrades this error to a
(yellow) warning.

don't prevent unsigned addon warning to not break some addons

This broke installing some, but not all, addons. The reason is that some
addons derive their addon-id from a certificate's CommonName in
XPIInstall.jsm::loadManifest(aPackage, aLocation, aOldAddon)

reword installation instructions

recreate all properties of AddonSettings automatically

Looks like all the settings continued to work by accident.

Note: out of scope for LegacyFox, but sideloading from anywhere can be
re-enabled by setting `SCOPES_SIDELOAD: 31 // AddonManager.SCOPE_ALL`.

Fix addon installation for Firefox 74

regressed by: Bug 1524327

provide clean and uninstall targets, auto-find correct path

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.

switch to resource:// protocol

bring the patch closer to the then-upstream comm-central. might have the
negative side-effect of being detectable by websites according to:
  https://developer.mozilla.org/en-US/docs/Mozilla/Chrome_Registration

don't overwrite chrome.manifest

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');

fix chrome.manifest loading for mozilla68

the chrome.manifest inside the install directory is not loaded any
longer by default; see bugzil.la/1543761

remove superfluous comments

add link to bug report to keep an eye on

credit where credit's due

remove boot.jsm

more portabe makefile

still has the mozillapath hardcoded, though

initial commit