Add option to generate string enums instead of numeric enums

[Stivin]

Hi! Add option to generate string enums instead of numeric enums for better OpenAPI integration.

Currently, @bufbuild/protoc-gen-es generates enums as numeric values following the protobuf specification. While this is correct for protobuf serialization, it creates significant issues when using these generated types for OpenAPI documentation and frontend code generation.

The problem

When protobuf enums are generated as numeric values and used in OpenAPI specifications, frontend code generators like @openapitools/openapi-generator-cli produce enum definitions with meaningless numeric keys:

export enum StatusEnum {
  NUMBER_0 = 0,
  NUMBER_1 = 1,
  NUMBER_2 = 2
}

Instead of meaningful enum names:

export enum StatusEnum {
  UNKNOWN = "UNKNOWN",
  ACTIVE = "ACTIVE", 
  INACTIVE = "INACTIVE"
}

Current workflow

Our typical workflow involves:

1. Using @bufbuild/protoc-gen-es to generate TypeScript types from protobuf contracts
2. Creating BFF (Backend for Frontend) layer that exposes REST APIs with OpenAPI specs
3. Using generated enum types in OpenAPI schemas for documentation
4. Frontend teams generating clients, types, and enums using @openapitools/openapi-generator-cli

The numeric enums make the generated frontend code unusable without manual intervention and custom mapping layers.

Proposed solution

Add a plugin option to generate string-based enums that preserve the original enum names:

// protobuf definition
enum Status {
  UNKNOWN = 0;
  ACTIVE = 1;
  INACTIVE = 2;
}

Current generation:

export enum Status {
  UNKNOWN = 0,
  ACTIVE = 1,
  INACTIVE = 2
}

Requested generation option:

export enum Status {
  UNKNOWN = "UNKNOWN",
  ACTIVE = "ACTIVE",
  INACTIVE = "INACTIVE"
}

Benefits

• Better Developer Experience: Frontend developers get meaningful enum values
• Reduced Boilerplate: No need for manual enum mapping layers
• Improved OpenAPI Documentation: Clear, readable enum values in API docs
• Seamless Integration: Direct compatibility with OpenAPI code generators