Building in Const Context

Ideally, the construction of a `WordFilter` could be done in a const context (see [Constant Evaluation](https://doc.rust-lang.org/reference/const_eval.html) for details on what can be considered a const expression). This would be much simpler to use than the current method of code generation within build scripts, and would allow for much clearer code on the user-end.

There are a number of things blocking construction as a constant expression. These will be enumerated here as they are discovered:

- [ ] Trait bounds on const fn parameters ([const_fn_trait_bound](https://github.com/rust-lang/rust/issues/57563)).
- [ ] Mutable references in const fns ([const_mut_refs](https://github.com/rust-lang/rust/issues/57349)).
- [ ] Heap allocations in const fns ([const_heap](https://github.com/rust-lang/rust/issues/79597)).
- [ ] Constant trait implementations ([const_trait_impl](https://github.com/rust-lang/rust/issues/67792)).

Implementation of `WordFilter` building in const contexts would involve the following:

- [ ] Move the logic within `word_filter_codegen::WordFilterGenerator` to a new struct `word_filter::WordFilterBuilder`.
- [ ] Builder should output the actual PDA inside the `WordFilter`. Logic within `WordFilter` should be able to remain the same.
- [ ] Make all internal PDA structs and modules `private`, as they are only currently public for the sake of the code generation.
- [ ] Migrate the `word_filter_codegen` PDA structs into the `word_filter` crate.
- [ ] Remove the `Visibility` enum, as it will no longer be needed.
- [ ] Deprecate the `word_filter_codegen` crate.

Implementation will be done on the `const_expr` branch. A working implementation will likely not be possible for a while, at least until the above blockers are solved via unstable features.