feat(mat-form-field): simplified errorstatematcher

### Feature Description

I've got a simple input field that just uses an ngModel for a username and password, and on error uses a signal for error state.

I would like to use signals to update the form's error state, but it seems like I need to bind an errorStateMatcher to a boring, repetitive throwaway chunk of code in my controller, because errorStateMatcher isn't just a boolean thing, it's an object that has one property (isErrorState) that is a function that takes some arguments etc. This is some java masquerading as typescript if I ever saw it (editorializing over).

### Use Case

```
class LoginControl {
username = '';
password = '';
status = signal({username: false, password: false});
async tryLogin() {
try {
await doSomeLogin(this.username, this.password);
} catch (e) {
if (e.badPassword) {
this.status.set({username: false, password: true});
// etc
```

in my template:

```

Password

^^^ what I want (or [simpleErrorState] if you don't want me overriding something important
woops

```

what I do instead is have to make

```
passwordInvalid = {
isErrorSate: () => this.error().password,
};
```

on my controller and boy howdy is that bad ergonomics. It's repetitive, and more importantly it obscures the real nature of the value. What if I accidentally do the wrong error property in the controller method? easy mistake to make when copy-pasting and hard to notice when the inlined value is not there.

As far as I can tell, the only reason this is the case is that we want to pass some lambda to the errorstatematcher, but it would *really* be great if these shiny new input signals and stuff would handle this.

Yes, I know I can just make a formgroup and write a reactive form. That's overkill and a ton of extra crust for two fields and a button.

AS AN ALTERNATIVE, I would accept: presence of a mat-error in the formfield automatically sets errorState to true, and then I can just wrap all these in `@if (error().email) { woops }` sorts of things. Based on the number of yaqs... i mean stack overflow comments I've seen about this, it seems like this is what a lot of developers think the behavior should be anyway. I'll admit that I thought the same thing. It's a little odd, having an API defined by "what child elements are in your tree" but you opened that door when you made mat-form-fields bind garbage on the child form input element. Not that I can think of a better approach here, honestly.

Start at the mat-form-field errorStateMatcher API and compare it with the template usage and controller workaround shown in the issue. Determine which proposed API behavior should be supported, then verify that a signal-driven boolean error state can be expressed without the repetitive matcher object and that the mat-error alternative behaves as intended.

Written by the indexing model from the issue text.