chore: rename package to vermock/vermockgen

Prior to this change, this package had been given the same name as an
other package which is already in widespread use within the community.
This does not cause a problem per se, but it does lead to aliasing
should a project choose use both or adopt one and migrate away from the
other.  This aliasing can lead to ambiguity when a naming convention
isn't agreed upon.  The problem can be even more difficult to diagnose
when you consider multiple installed binaries with the same name.

This change could recommend a naming convention to address such
situations but we have decided to take the more drastic action of
renaming the whole package while we are still pre-v1.  This mean
renaming the module, GitHub repository, the packages (root package,
./cmd/mockgen, ./internal/cmd/mockgen) and of course the README.

README.md

@@ -1,34 +1,34 @@
-# `mock` module
+# `vermock` module
 
-[![Go Reference](https://pkg.go.dev/badge/image)](https://pkg.go.dev/github.com/Versent/go-mock)
-[![Go Report](https://goreportcard.com/badge/github.com/Versent/go-mock)](https://goreportcard.com/report/github.com/Versent/go-mock)
-[![Go Coverage](https://github.com/Versent/go-mock/wiki/coverage.svg)](https://github.com/Versent/go-mock/wiki/Test-coverage-report)
+[![Go Reference](https://pkg.go.dev/badge/image)](https://pkg.go.dev/github.com/Versent/go-vermock)
+[![Go Report](https://goreportcard.com/badge/github.com/Versent/go-vermock)](https://goreportcard.com/report/github.com/Versent/go-vermock)
+[![Go Coverage](https://github.com/Versent/go-vermock/wiki/coverage.svg)](https://github.com/Versent/go-vermock/wiki/Test-coverage-report)
 
 Tired of mocking libraries with cumbersome APIs?  Frustrated with numerous and complicated options?
 Looking for a mock that works well with a composite of small interfaces or loves high ordered
 functions?
-Introducing `mock`, the simple mocking support that will enthusiastically accept a function that
+Introducing `vermock`, the simple mocking support that will enthusiastically accept a function that
 can be tailored to any bespoke test case.
-`mock` is guided by a central principle: test code must have full control of the code that runs in
-the mocked object.  This means mock behaviour has access to anything in the test fixture and the
+`vermock` is guided by a central principle: test code must have full control of the code that runs
+in the mocked object.  This means mock behaviour has access to anything in the test fixture and the
 `testing.T` value.
 This module provides a number functions that can be used as building blocks for your own mocks.
 
 ## Installation
 
-To use the mock module, ensure it is installed and imported in your project.
+To use the vermock module, ensure it is installed and imported in your project.
 
 ```go
-import mock "github.com/Versent/go-mock"
+import vermock "github.com/Versent/go-vermock"
 ```
 
-To use the mockgen command, simply run go run:
+To use the vermockgen command, simply run go run:
 
 ```sh
-go run github.com/Versent/go-mock/cmd/mockgen
+go run github.com/Versent/go-vermock/cmd/vermockgen
 ```
 
-After running mockgen for the first time, go generate can be used to regenerate generated files:
+After running vermockgen for the first time, go generate can be used to regenerate generated files:
 
 ```sh
 go generate
@@ -62,27 +62,27 @@ go generate
   }
 
   func (m *mockObject) Get(key string) (any, bool) {
-  	return mock.Call2[any, bool](m, "Get", key)
+  	return vermock.Call2[any, bool](m, "Get", key)
   }
 
   func (m *mockObject) Put(key string, value any) error {
-  	return mock.Call1[error](m, "Put", key, value)
+  	return vermock.Call1[error](m, "Put", key, value)
   }
   ```
 
-  Note that `mock.New` will panic if a zero-sized type is constructed more than once.
+  Note that `vermock.New` will panic if a zero-sized type is constructed more than once.
 
 3. (Optional) **Define Helpers**
 
   Implement Expect functions for greater readability. For example:
 
   ```go
   func ExpectGet(delegate func(testing.TB, string) (any, bool)) func(*mockObject) {
-  	return mock.Expect[mockObject]("Get", delegate)
+  	return vermock.Expect[mockObject]("Get", delegate)
   }
 
   func ExpectPut(delegate func(testing.TB, string, any) error) func(*mockObject) {
-  	return mock.Expect[mockObject]("Put", delegate)
+  	return vermock.Expect[mockObject]("Put", delegate)
   }
   ```
 
@@ -92,32 +92,32 @@ go generate
 
   ```go
   func TestObject(t *testing.T) {
-  	m := mock.New(t,
-  	mock.ExpectGet(func(t testing.TB, key string) (any, bool) {
+  	m := vermock.New(t,
+  	vermock.ExpectGet(func(t testing.TB, key string) (any, bool) {
   		// Define your mock's behaviour
   	}),
-  	mock.ExpectPut(func(t testing.TB, key string, value any) error {
+  	vermock.ExpectPut(func(t testing.TB, key string, value any) error {
   		// Define your mock's behaviour
   	}),
   )
 
   	// Use the mock instance in your test
 
   	// Assert that all expected methods were called
-  	mock.AssertExpectedCalls(t, m)
+  	vermock.AssertExpectedCalls(t, m)
   }
   ```
 
-### Using mockgen
+### Using vermockgen
 
-Alternatively, creating a mock implementation and associated helpers can be automated with mockgen.
+Alternatively, creating a mock implementation and associated helpers can be automated with vermockgen.
 Instead of implementing all the methods of your mock, simply declare the interfaces you want your
-mock to satisfy in an ordinary go file and let mockgen do the rest.
+mock to satisfy in an ordinary go file and let vermockgen do the rest.
 
 To continue the example from above this file would look like:
 
 ```go
-//go:build mockstub
+//go:build vermockstub
 
 package my
 
@@ -127,8 +127,8 @@ type mockObject struct {
 }
 ```
 
-This is an ordinary go source file with a special build tag: mockstub.  After running mockgen (see
-Installation above) a new file called `mock_gen.go` will be created with a new definition of
+This is an ordinary go source file with a special build tag: vermockstub.  After running vermockgen (see
+Installation above) a new file called `vermock_gen.go` will be created with a new definition of
 `mockObject` (the build tag ensures that these two definitions do not collide) containing all the
 generated methods and functions.
 
@@ -138,19 +138,19 @@ Be sure to checkout the Examples in the tests.
 
 ### Expect Variants
 
-In addition to the `mock.Expect` function, which corresponds to a single call of a method,
-there is also `mock.ExpectMany`, which will consume all remaining calls of a method.
+In addition to the `vermock.Expect` function, which corresponds to a single call of a method,
+there is also `vermock.ExpectMany`, which will consume all remaining calls of a method.
 
 Expect functions accepts a delegate function that matches the signature of the named method.
 The delegate may also accept a `*testingT` or `testing.TB` value as the first argument.
-This the same `testing.T` that was used to construct the mock (first argument to `mock.New`).
+This the same `testing.T` that was used to construct the mock (first argument to `vermock.New`).
 In addition, ExpectMany optionally accepts the method's call count.
 
 ### Ordered Calls
 
-The `mock.ExpectInOrder` will ensure that calls occur in a specified order.
+The `vermock.ExpectInOrder` will ensure that calls occur in a specified order.
 For example, this will fail if `Put` is called before `Get`:
 
 ```go
-mock.New(t, mock.ExpectInOrder(mock.Expect("Get", ...), mock.Expect("Put", ...)))
+vermock.New(t, vermock.ExpectInOrder(vermock.Expect("Get", ...), vermock.Expect("Put", ...)))
 ```

call.go

@@ -1,4 +1,4 @@
-package mock
+package vermock
 
 import (
 	"errors"

call_test.go

@@ -1,4 +1,4 @@
-package mock
+package vermock
 
 import (
 	"errors"