Only accept integer literals in `max_chars`

[iker-barriocanal]

Specifying max_chars equal to some string representation (i.e. environment) is confusing and obscures the intent of the operation. It's not immediately clear what a max_chars of environment means without introspecting the metastructure macro.

Defining max_chars limits to be associated to a particular field's limits leads to brittle code. Presumably the environment max_chars value could change if the internal representation of the environment column changes. But my environment field (or any field which relies on the environment max_chars value) may not change and so we would expect things to break in unexpected ways.

Additionally, adding more enumerations which are static and represent common length values (i.e. limit32, limit64, limit128) is unnecessarily constraining and still presents a risk of breakage if un-careful programmers change these values.

By allowing the programmer to specify an integer literal you ensure that that programmer is in complete control of their implementation and is at minimal risk of breakage from other programmers changing their implementations. New integer literals can be added without the programmer needing to make changes to the MaxChars enumeration. This improves the velocity of development and removes the barrier of introducing new validation limits.

### Tasks
- [x] https://github.com/getsentry/relay/pull/2587 (background)
- [ ] https://github.com/getsentry/relay/pull/2887
- [ ] https://github.com/getsentry/relay/pull/3422
- [ ] https://github.com/getsentry/relay/pull/3706

[iker-barriocanal]

Alternatives

1. Expose a constant for the length from relay-event-schema to relay-event-normalization.
   Pros: simple, removes MaxChars.
   Cons: adding max chars to new fields requires updating both crates, need to expose some random constants from the relay-event-schema.
2. Read and parse the field attributes of the metastructure in relay-event-normalization.
   Pros: extending max chars to new fields is easy, no constant exports.
   Cons: requires reading and parsing the attributes of the metastructure (hard to write and maintain) to get the value of the max char in the event normalization crate.
3. Accept using MaxChars is not that complicated and don't make more changes.
   Pros: no work required, we already know how it works.
   Cons: external contributors who don't know how it works may get confused.

[iker-barriocanal]

Proposed solution

• Use integers directly in metastructure.
• Keep MaxChars around for the cases where it's hardcoded. Ideally, MaxChars is moved to the normalization module.
  • Reevaluate if char size limiting could be moved to TrimmingProcessor without breaking changes.