feat!: deprecate string behavior classes

[agoose77]

As discussed in #2432, we don't appear to use these behavior classes anywhere. This PR deprecates them, and removes them from the global behavior dictionary.

This PR doesn't remove the behavior classes for byte and char, because these are used, including for == overloads.

• Deprecate string and bytestring behavior classes

[codecov]

Codecov Report

Merging #2528 (2ffa297) into main (f818083) will increase coverage by 0.03%.
The diff coverage is 87.20%.

Additional details and impacted files

Impacted Files	Coverage Δ
src/awkward/_util.py	90.00% <ø> (-1.08%)	⬇️
src/awkward/behaviors/string.py	74.49% <42.85%> (-1.90%)	⬇️
src/awkward/_operators.py	94.82% <94.82%> (ø)
src/awkward/_connect/numexpr.py	90.41% <100.00%> (+0.13%)	⬆️
src/awkward/_connect/numpy.py	94.53% <100.00%> (+0.03%)	⬆️
src/awkward/_connect/pyarrow.py	91.22% <100.00%> (+0.01%)	⬆️
src/awkward/_nplikes/numpy.py	65.45% <100.00%> (ø)
src/awkward/_nplikes/typetracer.py	76.65% <100.00%> (+0.37%)	⬆️
src/awkward/highlevel.py	76.82% <100.00%> (ø)
src/awkward/numba.py	97.01% <100.00%> (+0.02%)	⬆️

[jpivarski]

This is good. It removes all dependence on StringBehavior and ByteStringBehavior, making them essentially dead code, apart from the fact that they're a public API. It would be very weird for someone to be using these classes downstream, now that they're not a functional part of Awkward Array anymore, but deprecating, rather than deleting, is the right thing to do.

Let's merge this so that it gets into 2.3.0 on July 1. I've already added it to the list of deprecations.