Defer Sorter.DocMap packing until after flush

[Tim-Brooks]

IndexingChain calls sortMap.oldToNew heavily during flush — per posting
in FreqProxTermsWriter, per (field, doc) in DV writers, per vector in
KNN writers. The previous implementation built oldToNew as a
PackedLongValues, which is slow for that random-access hot path.

Build oldToNew as an int[] during flush, then pack to PackedLongValues
before storing on FlushedSegment, which is retained long-term on
ReadersAndUpdates for sorted segments with seg-private updates.

[Tim-Brooks]

During a flush reading packed values is a major performance hit. Particularly for points flushing.

Keeping the unpacked version for the life of the flush (still short) resolves this and Lucene already allocated the memory. The memory is still bounded by (directly) maxBufferedDocs and (indirectly) ramBufferSizeMB. I assumed it was unnecessary to add switches or configurations to tweak my proposed new behavior. But I can if that is desired.

For context a segment with 128K documents will take ~512KB for this int[]. Lucene already creates this for the initial sorter. It just releases it within the same method scope. I am proposing we keep it around for the lifetime of the flush and then release to a packed version once we have a sealed segment.