provide `errors.As` assertion

[deltics]

There is currently no mechanism for asserting that an error satisfies errors.As.

Two generic functions are provided for asserting that a value is of a specific type: ExpectType[T] and RequireType[T], both of which use type-assertion.

Options

1. Overload ExpectType/RequireType functions
2. Introduce new functions in the test package, e.g. ExpectError[T], RequireError[T]
3. Refactor ExpectType[T]/RequireType[T] functions as Type[T] in (new) expect and require packages

Option 1: Overload existing functions

When the type T and the value being tested both implement the error interface, the existing functions could assert using errors.As rather than a direct type assertion. However, this makes these functions more complex to use and could result in unintended passes (or failures) and also removes the ability to test the specific type of an error value, which these functions currently provide.

Option 2: New functions in the test package

Introducing ExpectError[T]/RequireError[T] adds more functions to the test package (intended to be .-imported). It also establishes a pattern of decorating Expect/Require with a suffix when introducing generic expectation functions. This could lead to similarly named functions in the future, further complicating the test package.

Option 3: New expect/require packages

Refactoring the existing functions into separate packages for fatal and non-fatal assertions establishes a clear and clean pattern that extends the test module while keeping the .-imported test package itself minimal, focused on the core (non-generic) Expect()/Require() functions.

The existing ExpectType[T]/RequireType[T] functions would be refactored as expect.Type[T]/required.Type[T] with new functions introduced (expect.Error[E]/require.Error[E]) for asserting an error using errors.As.