v1 <-> v6 transformation, v6 generation

[broofa]

The whole raison d'etre for version 6 is to provide interoperability with version 1. I.e. Version 6 is really only useful when operating in contexts where systems care about both version 1 and version 6 forms of a UUID (otherwise, version 7 should be used, instead).

Thus, I suggest our version 6 support should consist of the following:

• v1tov6(v1uuid) - converts v1 UUID to v6, throws if v1uuid is not actually version 1
• v6tov1(v6uuid) - converts v6 UUID to v1, throws if v6uuid is not actually version 6
• v6() - convenience method for v1tov6(v1())

Note: When converting v1 -> v6, RFC9562 suggests the node and clock_seq fields be replaced with random values per 9562. So there should be an option for this.

[github-actions]

Marking as stale due to 90 days with no activity.

[ludwhe]

Interested in developing this :) For v1tov6 and v6tov1, if the input is a buffer, what should be preferred between replacing the provided value in-place or returning a new buffer?

[broofa]

Return a new buffer. Modifying state in-place is a bit of a code smell, especially since we (this library's authors) don't know how the input id might be used subsequent to this method being called.