Feature Request: Form Signal Default Validation Messages Configuration

### Which @angular/* package(s) are relevant/related to the feature request?

_No response_

### Description

## Problem

Currently, when using Angular Signal Forms validators like `required()`, `email()`, `minLength()`, etc., developers must specify error messages for each validator call:

```ts
loginForm = form(this.loginModel, (schemaPath) => {
required(schemaPath.user.email, { message: 'Email is required' });
email(schemaPath.user.email, { message: 'Please enter a valid email address' });
required(schemaPath.user.password, { message: 'Password is required' });
minLength(schemaPath.user.password, 8, { message: 'Password must be at least 8 characters' });
});
```

This leads to:
- **Repetitive code** when the same messages are used across multiple forms
- **Inconsistent messaging** across the application
- **Maintenance overhead** when messages need to be updated globally
- **Reduced developer experience** due to verbosity

### Proposed solution

## Proposed Solution

Add a `defaultMessages` configuration option to `SignalFormsConfig`, similar to the existing `classes` configuration. This would allow developers to define default messages for validators that can be overridden on a per-validator basis.

## API Design Proposal

Extend the `SignalFormsConfig` interface to include a `defaultMessages` property

```ts
export interface SignalFormsConfig {
classes?: ..

defaultMessages?: {
required?: string | ((fieldName?: string) => string);
email?: string | ((fieldName?: string) => string);
min?: string | ((min: number, fieldName?: string) => string);
max?: string | ((max: number, fieldName?: string) => string);
minLength?: string | ((min: number, fieldName?: string) => string);
maxLength?: string | ((max: number, fieldName?: string) => string);
pattern?: string | ((pattern: string, fieldName?: string) => string);
// ... other validators
};
}
```

## Usage Examples

### Example 1: Simple Static Messages

```ts
import { provideSignalFormsConfig } from '@angular/forms/signals';

bootstrapApplication(App, {
providers: [
provideSignalFormsConfig({
defaultMessages: {
required: 'This field is required',
email: 'Please enter a valid email address',
minLength: (min: number) => `Must be at least ${min} characters`,
},
}),
],
});
```
### Example 2: Dynamic Messages Based on Field Name

```ts
provideSignalFormsConfig({
defaultMessages: {
required: (fieldName?: string) => {
const name = fieldName ? `${fieldName} is` : 'This field is';
return `${name} required`;
},
email: (fieldName?: string) => {
const name = fieldName || 'Email';
return `Please enter a valid ${name.toLowerCase()} address`;
},
minLength: (min: number, fieldName?: string) => {
const name = fieldName || 'This field';
return `${name} must be at least ${min} characters`;
},
},
});
```

### Example 3: Internationalization Support
```ts
provideSignalFormsConfig({
defaultMessages: {
required: () => i18n.translate('validation.required'),
email: () => i18n.translate('validation.email'),
minLength: (min: number) => i18n.translate('validation.minLength', { min }),
},
});
```

## Benefits

- **DRY principle:** Define messages once, use everywhere
- **Consistency:** Centralized message management
- **Flexibility:** Can still override messages per-validator
- **Maintainability:** Update messages in one place
- **Similar pattern:** Follows the existing `classes` configuration approach
- **i18n ready:** Supports dynamic message generation

### Alternatives considered

None