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.

Bắt đầu từ API errorStateMatcher của mat-form-field và so sánh nó với cách sử dụng trong template cùng giải pháp workaround trong controller được nêu trong issue. Xác định hành vi API nào trong số các hành vi được đề xuất nên được hỗ trợ, sau đó xác minh rằng có thể biểu diễn trạng thái lỗi boolean do signal điều khiển mà không cần đối tượng matcher lặp đi lặp lại, đồng thời xác minh rằng phương án thay thế mat-error hoạt động như dự kiến.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.