Support prefix overrides at the top level with `#[builder(on(...))]`

Start by reading the existing handling for #[builder(on(...))] and the code that chooses prefixes for Option setters. Use a minimal Foo example with value and label fields to compare the current maybe_ names with the requested configurable set_ names; done means the type-level override is defined and its generated setter names are verified.

Hi there,

First off, thank you for creating and maintaining Bon—it’s been a pleasure working with it!

As I migrate a codebase to Bon, I’ve run into a challenge with the naming conventions for setters handling Option fields. My current codebase uses set_ as the prefix for these setters. While Bon's built-in support for Option setters is a fantastic feature that removes the need for manual definitions, it uses the maybe_ prefix by default.

This mismatch means I still have to manually rename every setter to match my convention, which undermines some of the convenience.

I’d like to suggest two potential improvements to make this process smoother for me and other users:

1. Set set_ as the default prefix for Option setters (this align with naming in #142)
2. Introduce configurability for setter prefixes at the type level:
   Allowing users to define their preferred prefix (e.g., set_, maybe_, or custom ones) would offer greater flexibility and make Bon more adaptable to different codebases and conventions.

While either of the suggested changes would address my use case, I believe adding the ability to configure this at the type level would provide greater flexibility and cover a wider range of use cases.

Code snippet:

#[derive(Builder)]
#[builder(on(optional, prefix = "set_"))] // Example syntax for explanation, not necessarily the suggested approach
struct Foo {
    value: Option<String>,
    label: Option<String>,
}

A note for the community from the maintainers

Please vote on this issue by adding a 👍 reaction to help the maintainers with prioritizing it. You may add a comment describing your real use case related to this issue for us to better understand the problem domain.