Rationalize Resource-Timing opt-ins with CORS/CORP

Following a mailing list discussion and TPAC session, I'm opening up this issue to continue discussion.

At the TPAC session, we:

• Discussed the different categories of information Timing APIs expose and how we can reason about unifying the opt-ins for them.
• Concluded that while CORS does give you access to resource-level information (timing + size), it doesn’t currently provide origin-level or network-level information, so we shouldn’t extend its semantics to include those.
• Discussed whether CORP should enable exposure of resource size, which devolved into a discussion of the semantics of CORP, and whether it implies that a resource can be just embedded or embedded and read.

/cc @arturjanc @mikewest @camillelamy @annevk

Start with the linked mailing-list discussion and TPAC session notes, then review the unresolved questions about CORS and CORP opt-ins. The issue needs a settled proposal for which information each opt-in exposes and agreement on the resulting Resource Timing specification changes.