v2: vendor-neutral package names

[lhinderberger]

Since moving to v2 (#661) allows for breaking changes, I want to make the proposal to rename the packages from "redis" / "redisx" to something vendor-neutral in v2, in the light of the whole "Redis relicensing + multiple forks emerging" situation.

I think, since this library is primarily a RESP client that doesn't try to mirror a particular database's command set in Go code, such a name change would reflect that approach quite well.

One option could be to simply move the "redis" subpackage's contents to the top level and to rename "redisx" to "experimental".

[stevenh]

redisx was always experimental and will likely not get taken forward.

Even with licensing changes I suspect most will still know it as redis for some time to come, so I suspect keeping the package name would be the best thing from a discoverability perspective as well as from an upgradability one too as even with the move to v2 it would need to maintain the same name for imports and hence usage to not need significant work.

[lhinderberger]

Regarding discoverability, while I agree that as of now Redis is the better known name, I suspect that most people will probably use Valkey for new projects, and thus search for Valkey, not Redis, clients for their new projects too. So I don't know if keeping redis as a package name really helps discoverability.

As for upgradability: With v2, import paths would need to be find-and-replaced from "github.com/gomodule/redigo/redis" to "github.com/gomodule/redigo/v2/redis" anyway. If the redis subpackage is dropped, users that want an easy upgrade path could replace the import path with redis "github.com/gomodule/redigo/v2", to keep the redis. import prefix intact. That wouldn't make that much of a difference in terms of effort.