Get rid of ATN serialization restrictions (ATN states size can be > 65535, up to 2^31-1), remove excess serialization and allocations

[KvanTTT]

It's the limit of serialization, not of ANTLR tool itself. It can be and should be fixed. I've fixed it by using int serialization with varying bytes count that depends on int value:

public void writeCompactUInt32(int value) {
	if (value < 0b1000_0000_0000_0000) {
		writeUInt16(value);
	} else {
		writeUInt16((value & 0b0111_1111_1111_1111) | (1 << 15));
		writeUInt16(value >>> 15);
	}
}

All changes are back-compatible excluding quite large lexers or parsers (with more than 32768 states). But actually, it does not matter as I've said before because of version check on runtime.

If it's okay for Java, I'll fix other runtimes as well.

Fixes #1863, #2732, #3338

The PR depends on #3488

[KvanTTT]

Ok, I managed to save back-compatibility (up to 2^14-1=16383 that is also quite big) using the following encoding scheme:

encoding	count	type
00xx xxxx xxxx xxxx	1	int (14 bit)
01xx xxxx xxxx xxxx xxxx xxxx xxxx xxxx	2	int (30 bit)
1000 0000 0000 0000 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx	3	int (32 bit)
1111 1111 1111 1111	1	-1 (0xFFFF)

We only need positive integers and -1 (0xFFFF) for null.

All tests for other runtime works except a couple of tests with big lexers. But now ANTLR supports up to 2^31-1 integers and doesn't have any restrictions related to serialization.

Also, I've optimized both the tool and Java runtime, I've removed excess serialization and allocations. If the code is good, I'll fix other runtimes to support big lexers and parsers.

But anyway I prefer refactoring described in Optimization of ATN serialization format discussion.

[KvanTTT]

@parrt since #3488 is merged, this request is ready for intermediate review (Java only)

[KvanTTT]

I'm closing in favor of #3505