Fix OpenAPI v3 type naming issue

[henryjcee]

This PR modifies Goa's OpenAPI v3 generator to prevent de-duplication of explicit user types in the generated schema. this should address #3242. Presently, structurally similar types defined in the DSL e.g.:

var payload1 = Type("Payload1", func() {
	Attribute("foo", String)
})
var payload2 = Type("Payload2", func() {
	Attribute("foo", String)
})

Will result in a single entry in the generated v3 schema with an arbitrary name. After this change, Payload1 and Payload2 are generated as independent, named entries in the schema e.g.

"Payload1": {
  "example": {
    "foo": "Aut sed ducimus repudiandae sit explicabo asperiores."
  },
  "properties": {
    "foo": {
      "example": "Beatae non id consequatur.",
      "type": "string"
    }
  },
  "type": "object"
},
"Payload2": {
  "example": {
    "foo": "Vitae magni repellat minus minus dolor repellat."
  },
  "properties": {
    "foo": {
      "example": "Quas aut maxime aut non enim ullam.",
      "type": "string"
    }
  },
  "type": "object"
}

Issues

If you rely on type deduplication to generate your v3 schema, this may cause problems.

Testing

I've added a test case for this case and have formatted the test fixtures to a common style (hence the large diff). I'm currently using this fork to generate our public API docs and things are looking good.

Previous approach

As discussed with @raphael earlier, I've been looking at some ideas for fixing #3242. This PR takes a very dumb approach of merging openapi:typename tags into every Result and Payload DSL node, using the name from the endpoint.

This feels pretty bad and that's reflected in the fact that I've got test failures in quite a few places as a result of this. I do feel like this change should be taking place entirely within the openapiv3 package given that the problem appears to manifest only when generating OpenAPI v3 specs.

I am pretty new to Go and very new to Goa so I'd appreciate some eyes and advice on this if anyone has the time.

[raphael]

PR #3572 achieves the desired outcome and there are a few issues with this PR (the hashing still needs to happen in the OpenAPI generators) so closing in favor of the other PR.