@std/expect - export symbols required for matcher definition

**Is your feature request related to a problem? Please describe.**

I am developing a small library containing testing utilities.
I would like this library to provide an extended `expect()`, as documented for [expect.extend()](https://jsr.io/@std/expect/doc/~/expect.extend) (which is a great functionality BTW).
I would prefer defining my matchers in individual files and import them (exactly like [@std/expect does](https://github.com/denoland/std/blob/0796a25c9b6ab1eb007b56acab97827d7dd52f59/expect/expect.ts#L75)).

The problem is that I cannot type the context argument because [MatcherContext](https://github.com/denoland/std/blob/0796a25c9b6ab1eb007b56acab97827d7dd52f59/expect/_types.ts#L4) is not part of the package named exports.

Therefore, I cannot write a matcher like that:

```ts
export function toHaveSignature(context: MatcherContext, signatureExpr: string) {
// ...
}
```

**Describe the solution you'd like**

I'd like to be able to import [MatcherContext](https://github.com/denoland/std/blob/0796a25c9b6ab1eb007b56acab97827d7dd52f59/expect/_types.ts#L4) from one of the package's entrypoints.

```ts
import { MatcherContext } from "@std/expect";
```

Or even, if you want to keep the symbol footprint minimal for entrypoint designed for most users, to have a specific entrypoint for users who also need extra symbols for extension:

```ts
import { MatcherContext } from "@std/expect/extend";
```
or
```ts
import { MatcherContext } from "@std/expect/types";
```

I guess I could make the necessary changes, this is not especially difficult once agreement has been reached.

**Describe alternatives you've considered**

- Just write the matchers in a single file (which, honestly, would be fine for quite some time)
- Recreate the missing types (i.e. `curl https://raw.githubusercontent.com/denoland/std/refs/heads/main/expect/_types.ts > std_expect.types.ts`) and keep them in sync when there is a change.