Add type_attribute, field_attribute, and message_attribute support

[jlucaso1]

Adds prost-compatible type_attribute(), field_attribute(), and message_attribute() builder methods to buffa_build::Config, allowing custom attributes on generated types, fields, and message structs.

This is the main missing piece for migrating from prost when projects rely on custom derives or per-field serde attributes (feature-gated derives, #[serde(skip)] on specific fields, struct-only #[serde(default)], etc.).

Changes

Crate	File	What
buffa-codegen	lib.rs	3 new Vec<(String, String)> fields on CodeGenConfig
buffa-codegen	context.rs	matching_attributes() — prefix-matches FQN, parses into TokenStream
buffa-codegen	message.rs	Inject type/message attrs on structs, field attrs on fields
buffa-codegen	enumeration.rs	Inject type attrs on enums
buffa-build	lib.rs	3 builder methods with docs and examples

Path matching follows the same convention as prost: "." matches everything, ".my.pkg" matches a package prefix, ".my.pkg.MyMessage" matches a specific type. Partial segment matches are rejected (.my.pk does not match .my.pkg).

Follow-up

enum_attribute() (enum-only counterpart to message_attribute()) could be added in a separate PR if there's demand.

Closes #43

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[jlucaso1]

I have read the CLA Document and I hereby sign the CLA

[iainmcgin]

Approved. All review findings addressed in the maintainer-side fix-up; example demonstrates the feature end-to-end; 7/7 CI green.

[iainmcgin]

[claude code]

Thanks for this, @jlucaso1 — type_attribute/field_attribute/message_attribute was a real gap for users migrating from prost, and having the matcher shape mirror prost-build exactly will make those migrations painless. Merged!

A summary of the changes I made on top of your branch before merging, in case you're curious about the follow-up work:

Visibility and error hygiene

• Demoted CodeGenContext::matching_attributes from pub to pub(crate) — it's a codegen-internal helper and keeping it in the public API would have committed us to semver-stability we don't need.
• Added a typed CodeGenError::InvalidCustomAttribute { path, attribute, detail } variant and routed malformed attribute strings to it via ? propagation. Previously an unparseable attribute became #[doc = "buffa: failed to parse..."], which compiled fine and would slip past CI. Now the build fails loudly at the offending call site.

Oneof coverage

Wired type_attribute and field_attribute into oneof codegen:

• type_attribute(".pkg.Msg.my_oneof", ...) now reaches the generated oneof enum.
• field_attribute(".pkg.Msg.my_oneof.variant_a", ...) now reaches individual variants.

Previously both silently no-op'd, which would have been a surprising regression from prost for anyone migrating.

Matcher hardening

• Extracted matches_proto_prefix(prefix, fqn_dotted) -> bool so the proto-segment-aware logic (prevents ".my.pk" from matching ".my.pkg.Msg.data") is shared. Incidentally, this also fixed a pre-existing bug in use_bytes_type which was using plain starts_with.
• Trimmed trailing dots in the buffa-build normalizer via a shared normalize_attr_path helper, so users passing "my.pkg." (which could never match anything otherwise) get the same stored path as "my.pkg".

Tests and docs

• Added build-layer tests for the normalizer (leading-dot, trailing-dot, catch-all, insertion-order preservation) and codegen tests for the oneof coverage plus the parse-error path.
• Documented the duplicate-derive pitfall, the normalization rules, and the oneof reach in the type_attribute/field_attribute/message_attribute rustdoc.

Example

Added a demo in examples/addressbook: the Person.address.freeform_address oneof variant is now marked #[deprecated(note = "...")] via field_attribute, and the CLI stops offering it for new entries while still reading existing records that use it. This is the canonical deprecation-migration pattern and exercises the oneof-variant plumbing end-to-end.

Also worth flagging a semi-related change that landed between your PR's original push and this merge: #34 switched oneof enums to a uniform {Name}Oneof naming convention (previously only-on-conflict). If you had any downstream code referencing the old unsuffixed names, you'll want to update after pulling main.

Thanks again!