Maintenance: updating deps, icon chooser, and accommodating security policies

[mlwilkerson]

There are a few key things going on here:

Overhaul the admin JavaScript bundle

• use more up to date @wordpress/scripts for building the bundle
• simplify the webpack supplemental configuration
• remove React tests that relied on enzyme and related libraries to mount and test components in Jest tests (no longer compatible with later versions of React)

Accommodating the OWASP core rule set used by mod_security

An all too common problem encountered by users has been that their WordPress servers reject requests sent by the browser from our React code due to some security policy.

Turns out, the default OWASP core ruleset, which is probably what is often used for a "Web Application Firewall" via mod_security, has a couple of rules that are probably responsible for this:

1. Rejecting requests that use the PUT method

   There have been several requests in this plugin that use PUT. We've used that in part because the WordPress Plugin Developer Handbook for the REST API specifically recommends it:

   PUT should be used for updating resources.

   Perhaps some WordPress-specific installations of the OWASP ruleset are customized to allow the PUT method at least on the /wp/* core routes. Even if so, they may not allow PUT requests for this plugin's routes.

   In some cases, users have been able to get system administrators to add exclusions to allow these requests. But given how deeply baked in these rulesets are and how difficult it can be to diagnose the problem, and have the Web Application Firewall rules adjusted, it seems better to just change from PUT to POST.

   On a quick check of WordPress 6.5.4, using the block editor to update an existing page still uses a POST request, even though that seems like an obvious case of updating a resource. So it may be that WordPress itself does not even follow its own recommendation in this regard.

2. Rejecting requests that lack a Content-Type header

   The query handler for the icon chooser, while it has always used POST, has not added a Content-Type header. Since the default is text/plain, and the POST body has, in fact, been a plain text GraphQL query document, this seems Not Wrong. But it's also reasonable that the OWASP rules are strict about this. So this has been changed to use Content-Type: application/json, which is acceptable to OWASP.

Update the Icon Chooser

The icon chooser has been updated to dynamically populate the families and styles of icons available in the active version of Font Awesome. So, going forward, as new familyStyles are released, there'll be no need to update the icon chooser or plugin in order for those new familyStyles to become available in the icon chooser.

Closes #217