Ensure bundle plugin fields are available in fields

While Report Type plugins provide out of the box reports, end users will want to be able to build custom reports using Views. Since the reports are content entities this should "just work." But it needs to be verified. And maybe we should provide a test module with a sample View for testing and documentation.

I've spent some time trying to summarize the work currently being done in core that relates to this issue. It seems that there are some major bundle-related problems that need to be sorted out. This is the most directly relevant issue:

In Entity API Issue #2914091: Views filter handler for bundle field crashes for an entity with bundle plugins, @joachim proposes the following possible workarounds:

This could be fixed by providing a custom field handler for the bundle field for this sort of entity.

However, its probably going to come up on other views plugins too.

I think the best long-term solution would be to have entities that use bundle plugins automatically define a config entity type, and automatically create the bundle config entities in sync with the plugins. That would also solve a *lot* of issues wherever core expects entity bundles to be themselves entities.

I don't have any experience with views field handlers, but this may be the fastest (if not necessarily the right or best) path forward for order report plugins. Use hook_views_data_alter() to define the bundle fields for views and then create a field handler for each bundle field. After experimenting a bit, it seems that views just needs to be "told" where to find the data. (It looks for the bundle fields as a column in the commerce_order_report base table by default.)

If that won't work, here are some of the various core issues that seem most relevant:
1. Core Issue #2898635: bundleFieldDefinitions() are not added in EntityViewsData
* several patches have been created, most recent work was 4/20/18
* setName() and setTargetEntityTypId() are required to translated the config definitions into storage definitions.
* possibly blocked by core issue #2930736

2. Core Issue #2930736: EntityViewsData assumes BaseFieldDefinitions where it should use FieldDefinitionInterface
* The gist of the problem seems to be using FieldDefinitionInterface and FieldStorageDefinitionInterface objects interchangeably, which works for BaseFieldDefinition objects but not bundle fields:

EntityViewsData has the following code around line 252:
    // Load all typed data definitions of all fields. This should cover each of
    // the entity base, revision, data tables.
    $field_definitions = $this->entityManager->getBaseFieldDefinitions($this->entityType->id());
    /** @var \Drupal\Core\Entity\Sql\DefaultTableMapping $table_mapping */
    if ($table_mapping = $this->storage->getTableMapping($field_definitions)) {

* work has been done on this issue, but the current patch is not passing.

3. Entity API Issue #2817751: Create an API for bundle plugins
* This issue is closed/fixed
* Included in this summary only since it seems to relate to proposed solutions in core.

4. Core Issue #2346347: Finalize API for creating, overriding, and altering code-defined bundle fields
* Seems to me like too massive of an issue.

@kiamlaluno provided a summary of the current to-do items:

☐ Fix the problem hook_entity_bundle_field_info_alter() and hook_entity_base_field_info_alter() have (#2346329: hook_entity_base_field_info_alter() and hook_entity_bundle_field_info_alter() are documented to get a parameter that doesn't implement an interface with setter methods)
☐ Define a new class for bundle field definitions (#2935932: Add a class for bundle fields definitions)
☐ Correct the example given in hook_entity_bundle_field_info() (#2935932: Add a class for bundle fields definitions)
☐ Create bundle_field_override config entities (#2935978: Create a bundle_field_override configuration entity to override a bundle field with configuration)
☐ Update the documentation where necessary
☐ Update the code and remove the comments pointing to this issue, once this marked as fixed