Add support for alternate keys in code indexers

Notes from a conversation between myself and @baywet

The current OpenAPI specification says that the following is invalid
```
/pets/{petId}/fur
/pets/{name}/hair
```

However, I expect future iterations of the specification will relax this constraint and we know that these already exist in the wild. The notion of a collection of things having multiple candidate keys is a common concept and we should be able to model this.

We currently model these parameter segments as a CodeIndexer DOM model. Currently the CodeIndexer doesn't support the notion of alternate keys. We think it is worth exploring adding support for alternate keys to the CodeIndexer. We can continue to use the first parameter alphabetically as the default primary key, and all other parameters as alternate keys. This allows us to introduce support for a x-primary-key hint in the OpenAPI description that enables a particular path to be stable in its use of syntax like the C# indexer.

It may be possible that different candidate keys return different types. From a logical perspective the different types should be closely related, but from code perspective the types could be different. This does warp the concept of CodeIndexer slightly, but may be tolerable.

Adding this notion of candidate/alternate keys to the code indexer would remove the need for merging of nodes and the language refiners can emit specific named indexer methods for alternate keys and some default indexer method for the primary key, or they can emit specific named indexer methods for all the candidate keys.

_Originally posted by @darrelmiller in https://github.com/microsoft/kiota/issues/4174#issuecomment-1961616957_

Start by locating the CodeIndexer DOM model and the language refiners that currently handle parameter segments. Define how candidate and alternate keys, the default primary key, the x-primary-key hint, and differing return types should be represented and emitted. Done means alternate-key paths no longer require merging nodes and generated indexer methods follow the agreed primary-key behavior.

Written by the indexing model from the issue text.