Structural improvements: enhance headers handling

Following (again) ideas from OAI/OpenAPI-Specification#563 and OAI/sig-moonwalk#115, extending OAI/OpenAPI-Specification#369:

• define reusable response headers (like parameters or definitions as proposed in OAI/OpenAPI-Specification#563 by @fehguy )
• set responses headers on each level: whole api, path, operation, responses (and response as stated in OAI/OpenAPI-Specification#369)

paths:
  responseHeaders:
     # Headers returned on all api responses
  /resources:
    responseHeaders:
      # Headers returned on all /resources operations responses
    get:
      responseHeaders:
        # Headers returned on all operations responses
      200:
         headers:
           # Headers returned on this response
schemas:
  responseHeaders:
    # reusable headers describe with a Header Object, used with $ref

The problem is the naming consistency: responseHeaders almost everywhere vs headers on response level.
What if we use headers or responseHeaders everywhere?

nb: and don't forget to modify Header Object to include OAI/OpenAPI-Specification#321 (required)

Review the linked OpenAPI Specification issues #563, #115, #369, and #321, then compare the proposed responseHeaders and headers placements in this issue. Determine the consistent naming and Header Object requirements before changing the specification. Done means the structural proposal and required-header behavior are resolved and documented consistently.