Integrations: Extract into separate classes

[GaryJones]

Description

• Extract code for AMP and Facebook Instant Article integrations into new classes in separate files, out of the Parsely class.
• Improve and add tests that better check for the intended behaviour - adds 6 new tests and 19 new assertions.

It's the same behaviour for the end-user and site.

See #96.

Motivation and Context

The Parsely class does far too much, and needs to be split out into more logical classes to make it easier to maintain.

One area where this can be done is the extra code that makes the plugin work with other plugins i.e. integrations.

By creating a class for each integration, we logically group related code together, making it easier to see what integrations there are. The use of a collection and an interface (though this interface isn't yet checked for when registering an integration to the collection) provides a structure for built-in and other plugins to create their own integrations between Parse.ly and another plugin.

How Has This Been Tested?

AMP

1. With the AMP plugin not active, the amp_* filters won't run, so there are no negative side effects.
2. Install and activate the AMP plugin.
3. Visit any post and add /amp to the end of the URL.
4. Inside the source of the resulting page, look for a <amp-analytics opening tag that contains references to Parse.ly.

Facebook Instant Articles

1. With the FBIA plugin not active, the instant_articles_* filter won't run, so there are no negative side effects.
2. Install and activate the Facebook Instant Articles plugin. Visit the Settings->Permalinks page to flush the rewrite rules.
3. Visit the /wp-admin/admin.php?page=instant-articles-wizard admin page. If only one field is visible, enter any random string and save to then see many more settings.
4. Look for the Analytics section, and enable the Parse.ly Analytics checkbox.
5. Visit /feed/instant-articles and you should see XML. Look for the Parsely embed code from Parsely\Integrations\Facebook_Instant_Articles::get_embed_code().

Screenshots (if appropriate):

Coverage metrics for the new Integrations directory:

Integrations directory coverage compared to the rest of the plugin:

Integrations-related tests:

Types of changes

• Maintenance (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[pauarge]

This is awesome, it really improves the plugin structure! I left a minor question