Refactor base classes for extensibility

Problem/Motivation

The single reason for doing this is to allow other modules the ability to alter the SDK InstantArticle object without requiring the Display module.

Proposed resolution

Create a base wrapper class to wrap a FB Instant SDK article object with Drupal Base module configs and hooks for extensibility (without class inheritance, which the FB Instant SDK prevents by design).

Remaining tasks

1. PR creation
2. PR code/concept review
3. PR testing
4. PR merge
5. Make sure to note API changes in next release after this is merged
6. Link follow-up issue to support all Entity types (not just node)

User interface changes

None.

API changes

• hook_fb_instant_articles_article_alter() replaces hook_fb_instant_articles_display_instant_article_alter() (documented in fb_instant_article.api.php).
• New base module class (singleton wrapper + Drupal hook pattern): \Drupal\fb_instant_articles\ArticleWrapper.
• ArticleWrapper::create() allows setting a $context param when creating an InstantArticle object. The Display module sets entity_type and entity context before attaching the InstantArticle object to the Entity
• DrupalInstantArticleDisplay getArticle() and render() methods have been replaced by ArticleWrapper->getArticle()->render() (or $entity->fb_instant_article->render()).
• DrupalInstantArticleDisplay class has been renamed EntityWrapper.
• EntityWrapper::create now requires new params: $entity_type and $entity rather than $node (to support for all Entity types), and also now requires injecting an InstantArticle object $instantArticle.

Data model changes

• $node->fb_instant_articles_display_wrapper (previously contained the Display wrapper class), has now changed to $entity->fb_instant_article (now containing the Drupal-hook-altered SDK InstantArticle object retrieved from ArticleWrapper).
• Note that the refactoring also added generic Entity support (not only for node). Link follow-up issue here.

Original report by scotttrigby

Note we are changing our class pattern strategy from this initial idea due to SDK-imposed class inheritance limitations. See above.

This should:

• Be reusable inheritance for both RSS and API use.
• Invoking Drupal hook for building defining Transformer rules (using addRule rather than a JSON file and loadRules).
• Invoking Drupal hook for adding custom transformations (to be used by both the Display module, to call it’s extension class), as well as API use (without a dependency on the Display module, so that additional transformations – such as custom advertising services – can be placed within content HTML).