<vector>: vector doesn't comply with amortized time requirements near max_size

[BillyONeal]

When vector is trying to calculate geometric growth, if the result of such a calculation would itself overflow max_size, vector gives up and uses the new required size (which has already been bounds checked here):

STL/stl/inc/vector

Lines 1619 to 1621 in 3cca473

	if (_Oldcapacity > max_size() - _Oldcapacity / 2) {
	return _Newsize; // geometric growth would overflow
	}

This means that if someone were to call push_back repeatedly, for the last quarter of the max_size range, the container falls back to reallocation on each push_back.

This is super low priority because containers near max_size are usually impossible as memory consumption limits are reached long before this.

Instead of using the new size, we could fall back to max_size, choose a middle point between the desired size and max_size, or some other strategy; I mildly prefer just attempting max_size due to the simplicity thereof but customers who set a smaller max_size might expect a different behavior.

[BillyONeal]

This problem probably affects other places we do geometric growth too; whatever solution is used should probably be applied to them all.

[AlexGuteniev]

I like the immediate max_size attempt.
Guess the program is about to fail with `bad_alloc°, and the fix here is to make it fail faster.

Though I'm not sure if the problem exists at all. If more than a half of address space is allocated, then temporary new buffer would bad_alloc evw if it is just one element greater.