Automatically adjust heap size when close to compressed oops limit.

Setting a heap size close to but above the compressed oops limit is not a good idea. The benefit from the larger heap size is outweighed by the overhead of compressed oops.

For example: if the compressed oops limit is exactly 32GB, choosing 32.01GB instead of 32.00GB provides 10MB of extra space, at the cost of uncompressed oops across the whole heap, all but guaranteed to cost more than the 10MB gained. Thus we can say 32.00GB is a better choice than 32.01GB.

In reality, the compressed oops limit is slightly under 32GB, due to allowance for the null page and corresponding alignment. Predicting exactly how much under is not trivial. In practice, many users choose to use -Xmx31GB as the maximum realistic heap size for compressed oops. This means they miss out on up to 1GB of potential heap space.

Other users set -Xmx32GB because it's a nice number, or because they think it is the compressed oops limit, and they cross the threshold by a small amount, suffering uncompressed oops unnecessarily.

I propose to adjust the heap size if it is within some threshold of the compressed oops limit. I have chosen this threshold as 2% initially to be conservative while covering what I think is the most important use-case - Xmx32G. I suspect the ideal figure is higher.

Desired behaviour:
```
java -Xmx32G -version
OpenJDK 64-Bit Server VM warning: Heap size lowered from 34359738368 to 33822867456 to accommodate Compressed Oops
```

See also:
https://confluence.atlassian.com/jirakb/do-not-use-heap-sizes-between-32-gb-and-47-gb-in-jira-compressed-oops-1167745277.html
https://github.com/elastic/elasticsearch-definitive-guide/issues/370