- Design details updated
- 5th option based on API WG Alternate discussion
- Updated based on TEP review comments
- Updated based on Result Collector Sidecar
- Added Result Collector Sidecar author
- Updated with additional PipelineResource alternative'
- Updated based on PR comments
- Moved the result sidecar solution to alternative and marked as TBD
- Updated based on WG review feedback

…on 📓

In [a recent API working group meeting](https://docs.google.com/document/d/17PodAxG8hV351fBhSu7Y_OIPhGTVgj6OJ2lPphYYRpU/edit#heading=h.ux4qhojeot6k)
we talked through the proposal that was currently looking the most
appealing (sidecar + HTTP service) and @skaegi brought up some potential
requirements that might change this, and also volunteered to find
someone to work on a POC for a logs based solution before we disregard
that entirely.

Personally I agree that it would be best if we could keep the TaskRun to
be the source of truth for the results themselves, but that would mean
agreeing to an upper limit on result size (at least).

I've tried to reflect the above and generally organize the TEP a bit,
and add some missing stuff:
* Moved some points from Goals to requirements (really one goal overall,
  rest of the items are constraints on how we accomplish that goal)
* Add requirements we've been discussing, trying to highlight the ones
  that are newer and other collaborators might disagree with
* Expanding the risks section a bit
* Added some high level performance details
* Suggested potential next steps to unblock this
* Added more detials to auth/encryption/defined interface notes from
  our previous one off meeting
  [notes](https://hackmd.io/YU_g27vRS2S5DwfBXDGpYA?view)
* Filled in the design evaluation
* Added some drawbacks
* Separated "SideCar Result References" into two alternatives (which are
  not mutually exclusive)
* Added using PVCs as an alternative
* Added some cons to log based solution

I noticed this TEP is not yet accepted and merged. This TEP is stuck in the
review process. Dropping the proposal and design details based on the
recent discussion in the API WG. This TEP instead now contains a list of
alternatives. If we can merge this without proposal, it opens up an opportunity
for the community to create a PoC and evaluate which solution fits best for
the set of the requirements.

Moving the proposal and design details under the first alternative, making it
more like a TEP within TEP.

One major change here is the requirement section in which task results as part
of the taskRun status is listed as a requirement with the flexible design for
the use cases which would like to avoid it.

Updated the toc.

Co-authored-by: Jerop Kipruto <jerop@google.com>

Based on feedback by @bobcatfish