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)

Prüfe die verknüpften OpenAPI Specification-Issues #563, #115, #369 und #321 und vergleiche anschließend die in diesem Issue vorgeschlagenen Platzierungen von responseHeaders und headers. Bestimme die konsistente Benennung und die Anforderungen an das Header Object, bevor du die Spezifikation änderst. Als erledigt gilt die Aufgabe, wenn der strukturelle Vorschlag und das Verhalten erforderlicher Header geklärt und konsistent dokumentiert sind.