sidekick: handle enums with mixed naming conventions

Some enums values include the enum name as a prefix, e.g.:

```proto
enum Color {
COLOR_UNSPECIFIED,
COLOR_RED,
COLOR_GREEN,
COLOR_BLUE,
}
```

Rust strips this prefix so the generated code is more readable (Protobuf-gencode does too). We are doing the same thing in Swift. So the generated code is:

```swift
enum Color: Int, Codable, Equatable {
case unspecified = 0,
case red = 1,
case green = 2,
case blue = 3,
}
```

That works fine. It also works if the source specification does not use the prefix, so this thing:

```proto
enum Color {
COLOR_UNSPECIFIED,
RED,
GREEN,
BLUE,
}
```

Produces the same output. The problem arises if anything used mixed naming conventions like:

```proto
enum Color {
COLOR_UNSPECIFIED,
RED,
COLOR_RED,
GREEN,
BLUE,
}
```

None of the Google Cloud APIs seems to do this. They are unlikely to do so, that would be a blatantly bad naming convention. But we should consider changes to handle such a terrible enum. Maybe not strip the prefix in that case?

Start by locating the sidekick code that strips enum-name prefixes when generating Swift enums. Reproduce the mixed-prefix example and inspect the existing behavior for consistently prefixed and unprefixed values. Done should include a defined handling strategy for mixed naming conventions and generated output that follows it.

Written by the indexing model from the issue text.