Use bundle plugins for reports

I may be over-thinking this, but I'm wondering if we shouldn't have the only base fields be: order_id, created. Then we would have a CommerceOrderReport bundle plugin "OrderReport" that would add the amount field.

This may be a result of my lack of knowledge re: bundle plugins, but if we don't do it that way, would every other CommerceOrderReport bundle plugin also have to save the amount (which it may or may not be interested in)? And then it wouldn't be so easy to add additional order specific fields in the future (not sure what those are, just brainstorming).

Brings in #2918883: Remove tax_amount and shipping_amount from OrderReport base field definitions and #2918884: OrderPlacedEventSubscriber should pass initialized order report to report plugins, add a bundle plugin manager.

Right now we have only order id and created on the OrderReport entity. Plugin\Commerce\OrderReportType\OrderReport.php adds the amount field.

With this patch the very basic report is generated on order place.

We should probably just call it `commerce_report_type`

Makes sense. Is it safe to assume that would apply everywhere? e.g. Plugin namespace: Plugin\Commerce\OrderReportType. should be Plugin namespace: Plugin\Commerce\ReportType..

Update patch to remove Order|order when appropriate. This means we have @CommerceReportType instead of @CommerceOrderReportType and, e.g. ReportTypeInterface instead of OrderReportTypeInterface.

Just adding new lines where appropriate.

Via Slack Matt and I discussed using annotations to declare dependencies.

There is no need to do any dependency checking, plugins that we include which depend on other modules being enabled (e.g. commerce_promotion) should define a provider in their annotation.

I may be over-thinking this, but I'm wondering if we shouldn't have the only base fields be: order_id, created. Then we would have a CommerceOrderReport bundle plugin "OrderReport" that would add the amount field.

I'm coming back to this now that I'm looking at the actual creation of reports. I think it's very typical that for any report (promotion, stock, etc.) one would want the order total on each report. The architecture I've proposed makes that more difficult to join, e.g. a promotion report to an order report to get the amount. I *think* the best solution for this is to use an order_id entity reference field on each report. This makes it simple to join different reports.

I'm changing my mind again, and swinging in a different direction. I don't think the default report should contain order_id.

We have a CommerceReport Entity type that provides bundle plugin, commerce_report_type
- An OrderReport is a bundle with order_id, amount, etc.
- A single use promotion report can store order_id if we want
- A report such as an aggregate report that gets updated as necessary doesn't need an order_id

Aggregate reports are useful, having an order_id with them doesn't make sense.

Just in case there isn't enough variations in this issue, I'm attaching one more. This one presumes not all commerce reports are "order reports". So reports simply have uuid, updated, created. The included plugin, OrderReport, adds a report with order id and amount.

As I said previously, I'm finding aggregate reports to be more useful (and likely performant) but the entity having order_id as a base field doesn't make sense for that. Admittedly, I don't know anything about the 7.x use cases so I could be way off in thinking this is better.