Add enum_attribute API for enum-only Rust attributes

[iainmcgin]

Follow-up to #44, partly addressing #23.

The custom-attributes API from #44 has type_attribute (matches both messages and enums) and message_attribute (struct-only), but no symmetric enum-only filter. Users wanting to inject a derive like #[derive(strum::EnumIter)] on enums had to either also paint every matching message with the same attribute (which usually fails to compile, since the derive only makes sense on enums) or hand-construct an awkward union of multiple .type_attribute(".pkg.MyEnum1", ...) / .type_attribute(".pkg.MyEnum2", ...) matchers.

enum_attribute is the symmetric inverse of message_attribute.

API

buffa_build::Config::new()
    .enum_attribute(".my.pkg", "#[derive(strum::EnumIter)]")
    .files(&["proto/my_service.proto"])
    .includes(&["proto/"])
    .compile()
    .unwrap();

Same path-matching, normalization (leading-dot prepend, trailing-dot trim, segment-aware prefix), insertion-order accumulation, and CodeGenError::InvalidCustomAttribute semantics as the existing trio.

Codegen

In enumeration.rs, after the existing type_attribute match, also match enum_attributes and emit both attribute streams above the pub enum declaration. type_attribute continues to apply to enums as well — enum_attribute is additive, not exclusive.

Tests

• test_enum_attribute_on_enum_not_struct — catch-all enum_attribute lands on the enum but not on a sibling message struct.
• test_enum_attribute_scoped_to_specific_enum — prefix-targeted attribute lands on the matched enum only.
• test_enum_attribute_does_not_apply_to_struct — defense-in-depth check on the non-bleed property.
• enum_attribute_forwards_normalized_path — build-layer test confirming path normalization and that the other three attribute lists remain untouched.

Workspace tests, clippy -D warnings, rustfmt clean. No codegen drift.

Relation to #23

#23 originally asked for enum_attribute as a way to inject #[derive(strum::EnumIter)]. PR #49 (currently in flight) addresses the underlying use case directly by adding Enumeration::values(), removing the need for the third-party EnumIter derive in most cases. This PR adds enum_attribute because the API symmetry is still genuinely useful (e.g. for serde, schemars, custom derives) and the absence was an asymmetry surprise.