Prepare for release 4.0.0

[mlwilkerson]

This PR represents a significant overhaul, in preparation for a 4.0.0 production release. It will include:

1. The load configuration for Font Awesome is determined solely by the options set by the WordPress admin user.

   Other themes or plugins should still register themselves using the register() method, but this registers only their preferences, not requirements.

   The changes the logic of the plugin significantly, resulting in massive simplification, and also paving the way for better integration with kits.

   The admin UI will indicate to the site owner when a change of preferences would result in conflict with the preferences registered by other themes or plugins.

2. Integration with Conflict Detection.

   This will allow more surgical removal of conflicting versions of Font Awesome.

   It might result in a breaking change to the current "remove unregistered clients" feature, yet to be determined.

3. Re-designed admin UI

• Make sure conflicting preferences are being computed and reported to the admin client in a way similar to how requirements and conflicts were previously being reported
• Change update_item in the ConfigController
• Add back version as a preference that can be set using existing satisfies() function instead of semver
• Fix up the admin client app
• Rework the documentation for FontAwesome::conflicts() to reflect that all preference conflicts are indicated, not just the first conflict
• Change satisfies_or_warn() to be something like plugin_version_satisfies_or_warn() to disambiguate with testing Font Awesome asset version satisfaction in the preference conflict resolver
• Reconsider whether "Remove Conflicts" is a clear enough description for the feature formerly called "Remove unregistered clients". A concern is that it may be confusing at first, as to whether this removal of conflicts pertains to the conflict of preferences, provided by registered clients, or the conflict of Font Awesome loads introduced by un-registered clients.
• migrate the new conflict resolution code from the enhanced-conflict-resolution branch. And add tests for it.
• Design the conflict detection reporter widget
• Add test coverage for admin bundle load scenarios: with and without conflict detection enabled, and across front end, a login routes, and admin routes should include both those on our settings page and those on other settings pages. (This was a regression that needs coverage)
• Change how we render an error fallback view in the conflict detection reporter, so that it fits
• Reconsider what options and transients data to delete when deactivating the plugin. It may be more desirable to leave it.
• Determine whether to retain the equivalent of the old removeUnregisteredClients option in convert_options_from_v1().
  There's no exact equivalence between the two schemes, since the new scheme involves first enabling client-side detection, and then selecting which detected conflicts to blacklist. Probably we'll allow this to be a breaking change, and alert users upgrading that they'll need to use the new detection mechanism. We might want to put up an admin notice upon upgrade, and certainly include a note in the changelog.
• Add test coverage for FontAwesome_Config_Controller::update_item
• Streamline reporting of Release Provider exceptions: add integration test coverage for both normal runs of the plugin, and REST API responses
• Confirm that REST API controllers never return HTML, even when there's an exception
• Overhaul the API docs
• Overhaul README.md
• Update readme.txt where appropriate
• Improve error handling when a registered client causes a problem. For example, provides a version preference as [ '5.8.2', '=' ] (an array) instead of [[ '5.8.2', '=' ] ] (array of arrays). Currently, FontAwesome::satisfies throws an InvalidArgumentException in such a case, but the admin client just ends up with an opaque 500 error, which makes it seem like the plugin itself is broken, instead of showing that one of the clients is the root cause.
• Verify that plugin options persist across the plugin upgrade process. (And maybe consider the policy that they are cleared when deactivating).
• Add data-fa-detection-ignore to all elements added by this plugin
• Add support for selectively enabling removal of conflicts by md5 checksum (probably wait for a future release to automate the capturing of conflicts with the conflict detector)
• Remove   from shortcode rendering (see forum topic)
• double-check that the match in the script_loader_tag is still working correctly when adding the integrity key
• Fix BUG: lodash overwrites window._ in WordPress #52

[mlwilkerson]

Re-creating this PR as #58 due to changing branch name