Make SortField immutable

[romseygeek]

Description

Sort objects are shallowly immutable, but their inner SortField implementations are not, which could cause hard-to-track down bugs. We should make SortField immutable as well.

The field, type and reverse fields can be made final with no change in API. Missing values are trickier, as they are currently mutable via a setMissingValue method. My suggestion would be to deprecate this method in 10.4, and add constructors that explicitly take missing values (which could also enhance type safety); and then remove the method in 11.0.

[romseygeek]

The one remaining non-final method is comparatorSource which is only used by custom sorts. Given the tight coupling between SortField.Type and the comparator factory methods, I wonder if it makes sense to set comparatorSource for all types and add some basic factory methods to the various different FieldComparator implementations. Then SortField.getComparator() just becomes a simple call to comparatorSource.getComparator().

[SYEDMDSAAD]

@romseygeek That makes sense — moving the comparator creation logic out of SortField would both simplify getComparator() and avoid type-based mutation paths.

Before I start prototyping, should this issue aim for a full delegation model (all types backed by a FieldComparatorSource), or would you prefer an incremental step first (e.g., making existing state final and then refactoring comparator creation in follow-ups)?