Write VLong in opposite order for better outputs sharing in the FST

[gf2121]

Description

We also should really explore the TODO above to write vLong in opposite byte order -- this might save quite a bit of storage in the FST since outputs would share more prefixes. Again, separate issue 😀

From #12604 (comment)

Related to this TODO

[mikemccand]

This might be needle moving on the size of the FSTs created by block tree for the terms index, since it encodes long as vLong in its output. We should only try this "reverse vLong" in that context (private to FST encoding) ... e.g. it would not likely help for FST Outputs<Long> since the encoded output is a true long value not a byte[] leading with an encoded vLong and most of the written long values in that case will already be smallish.