Release 4.0.0-rc8

• Remove all composer dependencies, which were just Spyc (Yaml), Semver, and GuzzleHttp

  This is being done to eliminate possible namespace collisions between modules loaded by this
  plugin and those that may be loaded by other plugins that are activated along side this one.
  Our use of these third party libraries was only minor anyway, so eliminating them seemed better
  than trying a more complicated namespacing solution.

• Put all of this plugin's code into a FortAwesome namespace, for similar reasons. This is a breaking
  change for any client themes or plugins

• Convert the v3 icon map from yaml to a PHP associative array

• Update some developer docs: passing arguments to phpunit running in the container

• Fix up testing and mocking approaches, given changes in HTTP client: using wp_remote_get
  instead of GuzzleHttp Client

• Breaking: Move version specification out of the load_spec and into options

-- Design change: clients no longer register version constraints

-- Version is set based only on the options set by the site admin from the admin settings page,
with a default of 'latest' that resolves to the most recent version available from
fontawesome.com/api/releases

• Several methods like FontAwesome::options() now throw Exceptions when they would
  otherwise return invalid responses

• Refactor reset_db() into test support module

• Use reset_db() in more tests to avoid false negatives from db pollution by other tests running
  in the same test suite.

• Update integration testing plugins and theme with version and namespace changes

• Breaking: Re-implement FontAwesome::satisfies() and satisfies_or_warn() without reliance
  on Semver.

  Since we're not using the Semver library any more, we're also not using semantic versions any
  more wherever checking occurs. Replaced this with a basic (good enough) form of
  version constraints.

• Remove methods like get_latest_semver() that have become obsolete with semver changes

• Remove semver related properties from the json that is returned from the config controller
  to the React admin client.

• Deprecate the FontAwesome::load_spec() method

  The changes in this PR have made it more clear that it's probably time to re-organize and
  re-name a lot. This method name and the "load_spec" concept are foremost in need of
  such clean-up and clarification. In the meantime, comments have been added in the code
  and this accessor method has been deprecated to encourage developers not to rely on it.
  Everything it provides is otherwise available in more reliable ways, namely the other accessor
  methods like FontAwesome::version().

• Update API documentation to emphasize best practices with respect to registering requirements.
  In a nutshell: don't constrain unless you must.

• Breaking: remove the load_spec parameter from font_awesome_enqueued action

  Because of the misnomer that "load_spec" has become, rather than suggesting that client
  code can rely upon that load_spec to comprehensively represent the metadata of the load,
  developers should query the FontAwesome object's accessor methods.
  The font_awesome_enqueued action remains useful because it represents the time in the life
  cycle of the plugin's loading process when those accessor methods can be invoked and relied
  upon to provide accurate data.

• Update webpack-dev-server version to satisfy GitHub security warning

• Update cdn domains management url in the client

• Improve configuration exception handling

  Add a mechanism for bubbling up exceptions with user-facing notices, such as configuration
  errors upon attempts to save options in the admin UI that would produce invalid results.

  An example scenario: requiring webfont, v4shim, and a version earlier than 5.1.0.
  (No v4shim is available in that scenario, so a descriptive error is displayed in the admin UI,
  the result of a FontAwesome_ConfigurationException bubbling up from deep in the server code.)

• Change logic for updating db state: do not save options unless the entire load and enqueue
  succeeds. Previously, we weren't factoring in the possibility that conflicts may arise even after
  a successful load spec is computed, because an otherwise successfully computed load spec
  might still conflict with the site owner's selected options, such as version. Moving version from
  load spec to options highlighted this problem.

• Update Deactivator module to cleanup all db state on plugin deactivation

• Add fa_method() and v4shim() accessor methods to the FontAwesome object