feat: Add unique const random

[AlseinX]

The original implementation does not guarantee the generated number to be unique. This may cause problem when using it directly as a compile-time generated identifier.
So I added a unique version to make sure when a duplicate number is generated, it would simply re-generate it, until all possible values have been taken.

[dtolnay]

This is surprising to me -- in what case would you need a generated identifier that is both unique and random? I can understand needing unique identifiers, and separately needing random identifiers. Can you provide more information on your use case that requires both?

If you only require unique identifiers, a sequential count seems like it would be more appropriate for your use case. Is your reason to build it into this library just because some of the implementation is similar (like parsing the macro arguments)? If so, my preference would be not to extend this library in this way.

[AlseinX]

As for cases that require unique identifier, unless the identified items themselves are sequential, it would be better to use random identifier rather than sequential, otherwise some errors and vulnerabilities on identifier would be more likely to be soundless, because a valid id ± 1 would also be a valid id and sometimes they are relative.
There are certain to be many other reasons and examples that random identifier is choosed over sequential, and I believe that this feature is useful for many cases.

[tkaitchuck]

This might make sense for types like U64. But with u8 for example, I can easily imagine a case where due to dependencies more than 256 values get used. Then this creates the awkward situation where crates that build on their own don't build together (and in this case cause the build to go into an infinite loop).

I think the unique + random for smaller types like this it might be better to have tuple of (unique, random) which is used instead.