Possibility of accepting an interface instead of testing.T

### What do you want to see?

Hello,

we have implemented a custom struct that embeds `*testing.T` and adds some internal functionality, but does not change the interface.

Our custom struct looks something like this:
```
type Custom struct {
*testing.T
}

func (t *Custom) Errorf(format string, args ...any) {
// Some custom functionality here

t.T.Errorf(format, args...)
}
```

Using that custom struct with e2e-framework, however, is a bit difficult because funcs like `Test` in the `Environment` interface (see [here](https://github.com/kubernetes-sigs/e2e-framework/blob/d00c1c8d5295149a9db64fbcd706e36d3b747141/pkg/types/types.go#L74)) require a concrete `*testing.T` type instead of an interface.

Would it be possible to accept an interface instead, like `testing.TB`? Are there specific reasons why the concrete type was chosen instead of an interface? For reference, testify even has an [own interface](https://github.com/stretchr/testify/blob/feb1324bc3d000fed7b21dfe20bec72ecca27502/assert/assertions.go#L30), which makes using custom wrappers like ours straightforward to use.

Thank you!

### Extra Labels

_No response_

Start with the Environment interface and its Test method in pkg/types/types.go, then trace the implementations and call sites that pass *testing.T. Check the existing test coverage for these APIs; done means the accepted test type supports the described wrapper while preserving existing framework usage.

Written by the indexing model from the issue text.