Improve library "ergonomics"

[mareek]

Following the discussion in #5 , I will limit the public surface of the API and add more comments for developers that want to dig further than the few methods in the Uuid static class.

• make all generators internal as they are not meant to be used directly (or maybe just their constructors ?)
• remove non used generators (V3 and V6)
• add some comments in UuidV8SqlServerGenerator to explain the reasons of this implementation (see UUIDs are not sorted properly in a MSSQL DB at scale #2)

[QianMoXi]

I noticed that the new method of the UuidTimestampGeneratorBase class has been changed to internal in version 3.0.0-beta, can it be modified back to public?

Because I support Sql Server and My SQL in the same app, and I injected the UuidTimestampGeneratorBase class into DI to generate IDs for different rules.

[mareek]

The reason that I'm making the generator classes internal is to prevent some misuse I've seen in some code base. These classes were not intended to be used outside of the library; it was a sloppy move from my part not to make them internal from the start.

For your use case, I recommend writing some code like this and using IUuidGenerator in the places where you used UuidTimestampGeneratorBase

using UUIDNext;
public interface IUuidGenerator 
{ 
    Guid NewUuid(); 
}

public class SqlServerUuidGenerator : IUuidGenerator 
{ 
    public Guid NewUuid() => Uuid.NewDatabaseFriendly(Database.SqlServer); 
}

public class MySqlUuidGenerator : IUuidGenerator 
{ 
    public Guid NewUuid() => Uuid.NewDatabaseFriendly(Database.Other); 
}

You can also still use UUIDNext V2.0.2, there are no significant change in the UUID generation.

P.S. Sorry for the delay in answering your comment