Refactor SortField to better handle extensions [LUCENE-9326]

Working on #10365 has made me realize that SortField needs some serious reworking:
- we have a bunch of hard-coded types, but also a number of custom extensions, which make implementing new sort orders complicated in non-obvious ways
- we refer to these hard-coded types in a number of places, in particular in index sorts, which means that you can't use a 'custom' sort here. For example, I can see it would be very useful to be able to index sort by distance from a particular point, but that's not currently possible.
- the API separates out the comparator and whether or not it should be reversed, which adds an extra layer of complication to its use, particularly in cases where we have multiple sortfields.

The whole thing could do with an overhaul. I think this can be broken up into a few stages by adding a new superclass abstraction which `SortField` will extend, and gradually moving functionality into this superclass. I plan on starting with index sorting, which will require a sort field to a) be able to merge sort documents coming from a list of readers, and b) serialize itself to and deserialize itself from SegmentInfo

---
Migrated from [LUCENE-9326](https://issues.apache.org/jira/browse/LUCENE-9326) by Alan Woodward (@romseygeek), updated May 26 2020
Sub-tasks:
- #10370