Optimize ejb timer id while maintaining type compatible with existing timers

ejb timers currently use UUID as their timer id, and primary key when persisted to database. There are some drawbacks with UUID-based timer id:

• expensive to generate
• very long, and not human-readable
• takes too much memory space to cache the id fields large number of timers
• UUID values are all random and hinders database operations like insertion, indexing, retrieving.
• UUID version 4, which is the one used in timer id, is not 100% guaranteed to be globally unique, though duplicates are unlikely. See UUID Wikipedia collision section. "...collisions can occur even without implementation problems, albeit with a probability so small that it can normally be ignored...the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion." 

In a related issue, WFLY-15568 explores the possibility of switching to an int-based timer id, but that will not work with existing implementation and timers, which use string timer id. Int timer id can be a long-term task.

In the meantime, we should be able to design a string-based timer id, and avoid the above drawbacks at the same time, and still be fully compatible with existing implementation and timers.