Investigate replacing size_t as the RpcClient ID

[gregmedd]

It is possible that, in long-running systems with high volumes of RPC requests, uE code could be written in such a way that the client ID used for tracking pending RPC requests could roll over, resulting in value reuse. This scenario would require that RpcClient instances are regularly being created and destroyed. While this is not an expected use pattern, if it were to occur pending requests for the original owner of a given client ID would be discarded when the duplicate owner is discarded.

From review call: on 64-bit systems, we don't expect this to ever be a problem. We can make the 1.0.0 alpha.2 release and consider alternatives if needed.

Originally posted by @gregmedd in https://github.com/eclipse-uprotocol/up-cpp/pull/202#discussion_r1674667751

We believe this is relatively unlikely in the near term and that this issue should not block the alpha.2 release.

One proposed solution is to use the UUID generator instead. While there is a real compute cost to making that switch, we are already generating UUIDs for every request and response, and RpcClient instantiations are expected to be created no more often than request messages in the worst-case scenario (and orders of magnitude less frequently in typical uses). Any scenario where RpcClient instances are created and destroyed more frequently than RPC requests are issued within a uE is already pathological such that the hit to performance is not a concern.