Proposal for alternative report storage (aggregation API / extension API server)

[stone-z]

Opening in parallel with #50 to avoid a massive PR review, but please take whichever is preferable for the maintainers.

Much of this is now very nicely captured by @vishal-chdhry's PR, this draft is just to capture the background we've done at Giant Swarm so the maintainers can consider and incorporate any notable differences. I had wanted to open this sooner, but other priorities and my inability to publish something until it is "perfect" got in the way 😅 thanks for your patience.

The most notable additions / differences between this and the current state of the other PR, as I see it, are:

• my proposal includes storing other types beyond PolicyReports. There are more types which suffer the same issue -- this component can solve the issue for them as well.
• in my mind, this subsystem makes the most sense if report types are considered ephemeral. If reports are understood to be regenerated if deleted, migration is a nice to have but not strictly necessary, and guarantees about the RDBMS can be more relaxed. Preserving historical data has been a stated non-goal of this database -- it is only intended to reflect the "current" cluster state. Reports should be shipped to external storage for long-term archival.

[realshuting]

Reports-server is available https://github.com/kyverno/reports-server.