Allow ComposedSchemas to replace non-composed so we can respect polymorphic links discovered in later methods

[slw546]

Paths are inspected in reverse alphabetical order, with the first schema generated any inserted into components taking precedence.

Therefore if you have paths e.g.

    @GetMapping("/any")
    public Pet aaaagetAnyPet() {
        return new Cat(true, "cat");
    }

    @GetMapping("/zzzzzdog")
    public Dog zzzzgetDog() {
        return new Dog(true, "dog");
    }

...
class Dog extends Pet
class Cat extends Pet
class Pet

We'll generate Dog first by inspecting zzzGetDog, which isn't composed because we are returning Dog directly.
We then generate Pet and subtypes when we find the other method. At this point we should replace the existing Dog component with the new composed one, as we're now aware that we care about the polymorphism, but the existing code skips the existing key for Dog, meaning the spec incorrectly presents Dog as unrelated to Pet.

Meanwhile, as Pet and Cat were not previously generated, Cat is correctly emitted as a subtype of Pet with an allOf Pet reference.

As far as I can tell, this issue hasn't cropped up before in examples or existing tests because the path naming has always been such that Pet generated first by conincidence, which meant a ComposedSchema for Dog would already be present in the components.

[bnasslahsen]

@slw546,

Thank your contribution to the project!