Consider shorthand for encoding method with path, eg; post /foos/{id}

[rattrayalex]

paths:
  "post /speakers":
     requests: 
       createSpeaker:
         contentType: application/json
         …

as shorthand for

paths:
  "speakers":
    requests:
      createSpeaker:
        method: post
        contentType: application/json
        …

Relates to this proposal to allow a request shorthand: #60 and could perhaps be merged there, as it would make it much more common to be able to use a single request key, e.g.:

paths:
  "post /speakers":
     request: 
       contentType: application/json
       …

Part of my motivation here is that it always felt strange to me that "retrieving" and "updating" a resource in an OpenAPI spec are nested in one place, but "creating" and "listing" the same resource are nested separately. Why nest at all? We're ultimately trying to get a flat list of operations. If we really do want to organize operations somehow, doing it based on resources might make a bit more sense.