[PATCH] InstanceId

Added InstanceId to uniquely identify concurrent messages, transactions,
etc.

Use InstanceId for async job and calls identification.

Side-effect: removes inconsistent prefixes for job debugging: ecapxN,
icapxN, asyncN are now all jobN, simplifying searching and processing
debugging logs.

-----------

We have a few classes that use mostly unique identifiers for debugging.
More are coming, including MemBlob from the StringNG branch and IPC
messages used by SMP code. The classes I know about benefit from having
sequentially increasing IDs, specific to the class. For example, it is
very convenient to have async jobs numbered 1,2,3,4,... because it often
preserves the job number during repetitive debugging and also shows the
relative "distance" between the jobs.

The first attached patch adds a InstanceId class that encapsulates the
identifier maintenance logic. The second shows how the new class can be
used in the existing code.

Beside the general review, here are a few specific discussion points:

We can force hex formatting for printed ID values. This will shorten
printed IDs, but will also make them a little bit more difficult to
find/see in the logs. Please let me know whether you think we should use
hex.

We can also move custom "created/destructed" debug messages to
InstanceId, but I am not sure that is a good idea because it will either
remove constructor parameters from those lines or will force us to use
two debugging lines per constructor (one standard and one custom). I
think it is better to add global functions to standardize output prefix
than ask InstanceId to emit "created/destructed" debug messages. What do
you think?

Currently, InstanceId uses "int" to store ID values. I am not aware of
any classes that need unique IDs with storage types other than int
(e.g., to save space or further minimize wrapping). If there are such
classes, we need to make the storage type into a second template
parameter. Please let me know if you know of such classes.

Thank you,

Alex.