Bindgen has way too many options

[pvdrz]

BindgenOptions has reached 100 fields recently which is both awesome and worrying 😅
.
We should consider ways to decrease this number. One of these could be grouping some options that share the same functionality like the allowlist_.* family of methods (which currently has 4 methods). We could have a single method:

impl Builder {
    fn allowlist<T: Into<String>>(self, kind: AllowlistTargetKind, pattern: T) { ... }
}

enum AllowlistTargetKind {
    Var,
    File,
    Type,
    Function,
}

This would simplify the API and unify the documentation about allowlisting in a single method, meaning that if we decide to change the default behavior we wouldn't have to update the docs of several methods.

The same could be done at the CLI level by adding --allowlist=<KIND>=<PATTERN>. However, this does not come without drawbacks. So we should ponder whether to apply this change to the CLI arguments or not.

There are other families of methods where this could also apply:

• blocklist_.* (4 methods)
• derive_.* (8 methods)
• no_.*: no_copy, no_hash, etc. (5 methods)
• impl_.* (2 methods)
• bitfield_enum, newtype_enum, newtype_global_enum, rustified_enum, rustified_non_exhaustive_enum, constified_enum and constified_enum_module (7 methods).
• type_alias, new_type_alias and new_type_alias_deref (3 methods).
• bindgen_wrapper_union and manually_drop_union (2 methods).

If we were to do this change, we would remove 35 methods and add 8 new ones. This change could be done gradually by first:

• Introducing the new methods.
• Marking the old ones as deprecated changing their implementation to be calls to the new ones.

Then, we could remove the deprecated methods in a future version.