(dev/core#4279) Add configuration option for ESM loader

(dev/core#4279) Add configuration option for ESM loader

(a) I don't really care about customizing `esm_loader` via web UI on a
day-to-day basis. It's not terrible that the web UI has the setting,
but that's not the main point. So why have a setting?

(b) When/if some CMS or CMS-addon causes a break in ESM loading, the
site-builder should be able to swap loaders and work-around the problem.
Neither loader is invicible, but they have some complementary failure-modes.
Compare:

  - If the conflict is two browser-level "importmap"s, then switching
    Civi to "importmap-shim" (`esm.loader.shim`) should work-around that.
  - If the conflict is two copies of "es-module-shims.js", then switching
    to basic "importmap" (`esm.loader.browser`) should work-around that.

(c) I went back/forth on whether the configuration should be a constant
(`CIVICRM_ESM_LOADER`), setting (`esm_loader`), or something even more
esoteric. In the event of a failure/conflict, settings provide the most
media through which the site-builder can enable a work-around, eg

  - Edit `civicrm.settings.php`, or
  - Edit `/etc/civicrm.settings.d`, or
  - Use CLI like `cv vset` or `drush cvapi`
  - Use browser console like `CRM.api3` or `CRM.api4`
  - Use REST API

(d) When/if there's a conflict, the long-term fix will (probably) be
implementation of another loader (`esm.loader.drupal` or `esm.loader.wp`)
based on some future API. At that point, we would need to change the default
for that environment (*without changing defaults for anyone else*). Hence
the support for dynamic defaults (a la `prevNextBackend` or `assetCache`).