Consolidated $ref-to-Some Object feature request

[handrews]

This issure consolidates and replaces the numerous "can the OAS allow $ref for..." issues:

• Security Requirement: Add security to the components object #1850
• Security Scheme: How do I refer to external securitySchema object ? #1972 (but see also Use URI references for Security Requirements in 3.2 #3776 for an alternative)
• Server: change specification to permit $ref of server objects #2338
• Tags: Allow the use of $ref and json pointer in tags #2905
• Operation: Feature Request: $ref for Operation Object  #2922 (but note that there are impacts on finding and resolving operationId)
• Media Type: Allow $ref in request body and response content objects #3056 (closed because the specific use case is handled by overriding description with a Reference Object); also Reusable media types #2845 although there is more to that one)
• Contact: [feature] support of $ref in contact fields  #3552
• License: [feature] support of $ref in licence fields #3569

[handrews]

It's worth noting that all of these are at least a bit more complex than they initially seem:

• [NOTE: URI references of some sort were considered and rejected for 3.2, and we are unlikely to revisit them without new motivation] Tag Objects are in an array, and JSON Pointer fragments to an array are confusing and fragile
• Added in 3.2! Security Requirement Objects involve an unusual lookup to Security Scheme Objects (although see Use URI references for Security Requirements in 3.2 #3776)
• Server Objects are looked up based on their parent Object – I think that wouldn't be too much of a problem because you'd look up based on the $ref source and not on the actual location of the Server Object, but that would be a new complication to resolving things
• Operation Objects require context from parent Path Item and Paths Objects to function, which is already a problem for Link Objects (see Link Object (and Arazzo?): require referencing operation with unambiguous path template #4084 for more information)
• Added in 3.2! Media Type Objects require the media type from the parent field - while it is possible that the same Media Type Object could be used for different Media Types, this pattern would be a bit unusual and would require some thought
• It's not all that clear to me how $ref for Contact and License would be used. If we just want to avoid having to repeat these objects in each document in a multi-document OAD, I'd probably rather just relax the requirement that they be present in non-entry documents