Make it easier to define link headers

[ePaul]

RFC 5988, section 5 is defining the LinkHTTP header.
It is mainly used on responses to GET requests (but can happen on any kind of response), but can also be used sensible as request headers for PUT, and possibly for the (less common) LINK and UNLINK methods.

It can look like this:

Link: <http://example.com/TheBook/chapter2>; rel="previous";
      title="previous chapter"

or this (having a list of two links):

Link: </TheBook/chapter2>;
      rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
      </TheBook/chapter4>;
      rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

(Examples are from the RFC.) As usual with HTTP headers, you could have written this last example also in two headers, like this:

    Link: </TheBook/chapter2>;
          rel="previous"; title*=UTF-8'de'letztes%20Kapitel
    Link: </TheBook/chapter4>;
          rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

I would like to be able to define that a link with a certain relation type (the value of the rel attribute) will/might be available in the response (or must/can be sent in a request). Currently (with OpenAPI 2.0), the best I came up with was this:

      responses:
        200:
          description: Retrieval was successful.
          headers:
            Link:
              type: string
              description: |
                Links to related resources, in the format defined by
                [RFC 5988](https://tools.ietf.org/html/rfc5988#section-5).
                This will include a link with relation type `next` to the
                next page, if there is a next page.

I guess I could make this an array and use collectionFormat: csv, though I'm not sure how either of these would handle the two-headers version.

For OpenAPI.next (i.e. 3.0, if possible) I would like some better way of doing this, including to say links of which relation are expected to be there (but not forbidding other ones, of course).

I might be that the "parameters can have schemas" (in #654) with serialization strategies (in #665) might help here, if it gets extended to response headers, too, and we get a special serialization strategy for those kinds of headers.

Any other ideas?