Avoid busy-spinning when time UUID timestamp capacity is exhausted

Problem

cass_uuid_gen_time() can allocate 10,000 unique 100-nanosecond timestamps per millisecond. Once a shared generator exhausts this capacity, callers busy-spin until the wall clock advances. Workloads above roughly 10 million UUIDs per second can therefore consume CPU and incur latency.

Options

• Yield: preserve timestamp behavior and let other threads run, but potentially reduce peak throughput and still use substantial CPU.
• Advance the timestamp: remove the limit and spinning with a simple implementation, but allow generated timestamps to move ahead of wall time and diverge from the legacy driver.
• Sleep: preserve timestamp behavior and reduce CPU use, but risk scheduler oversleep, extra latency, and lower throughput.
• Keep current behavior: retain legacy compatibility and current benchmark results, but keep busy-spinning above the limit.

Benchmark single- and multi-threaded workloads, select an approach, and update implementation, tests, and documentation.

Related: #506.

Start with the cass_uuid_gen_time() entry point and run the single- and multi-threaded workloads requested in the issue to compare yielding, advancing the timestamp, sleeping, and the current behavior. Done means one approach is selected from the benchmark results, with the implementation, tests, and documentation updated accordingly.