Reconsider Thread::cooked_allocated_bytes()

The existing mechanism is problematic in that it is racy; it reads TLAB pointers updated by another thread. It attempts to parry for reading inappropriate values by comparing the used_bytes against the max_tlab_size, to avoid reporting values considered entirely off. A safer means would be to pick up and report only the bytes the owner of the tlab reported already (i.e. _allocated_bytes), but this would mean the reported value would trail by one tlab, and the impact of doing this is currently unknown. It could also involve introducing some protocol in how the threads publish their values from their TLABs. Or perhaps this race, with its current workaround, can be considered benign?

The problems with this function became manifest with JDK-8260046. JDK-8267579 introduced a workaround to help reduce the overall impact of this problem, as seen in general testing.