Easy-digital-downloads: Create an API to build and render reports

[DrewAPicture]

| PR | Relies On | Tracking | Project |
------ | ------------ | ----------- | ------------
| ~#6289~, ~#6329~ | ~#6254~, ~#6280~ | #6236 | 3DD™: Reporting API Reboot

Background

This primarily builds off of the work being done in #6254 and #6280. Once the report and endpoint registries are in place, we'll need to introduce an API for actually rendering the pieces stored in those registries.

The thinking is that, just as Endpoint objects are being built from Endpoint_Registry entries in #6280, the process of instantiating a report for display should work similarly.

More specifically, a call will go out for all registered reports to be instantiated as Report objects, with the view type for endpoints set by virtue of inclusion in specific view lists in the report registry entries. For example, if a report is registered with several endpoints under a tiles key, all of those endpoint records will be instantiated in the Report object with the view and data model logic in place for the tile view type.

It should be possible to both retrieve a registered report and instantiate one on the fly (as well as retrieve registered endpoints and/or create them on the fly). This approach allows for the greatest level of flexibility in extending the new reports API.

Ideally, at the time of instantiation, the Report object should contain all of the necessary information for display short of actually having performed the queries set out in the data model corresponding to the endpoint views. This allows for loading much of the endpoint data just-in-time (JIT).

[DrewAPicture]

WIP PR: #6289

[DrewAPicture]

Merged #6289. Moving forward now with rendering logic.

[DrewAPicture]

Started a WIP PR for reports rendering logic: #6329

[DrewAPicture]

Merged #6329. Leaving this open for more future changes.

[DrewAPicture]

Actually, I'm going to close this in favor of new issues for anything new that comes up in the spirit of forward progress.