Repository: pydantic/pydantic

Issue:
Clarify "always" usage in validator migration guide and field validator doc
### Initial Checks

- [X] I confirm that I'm using Pydantic V2

### Description

Hello team,

First of all, thanks for the great work! And sorry if this request is not qualified as a "bug"

Context: 
I am currently migrating from the v1 API to v2 and encountered a small hurdle related to the usage of `always` in the validator section.

While going through the pages, I found it slightly convoluted to find the doc with this particular migration or at least identify the closest alternative in the v2 API. After some exploration, I stumbled upon the `validate_default` argument in the Field API, which seems to offer the closest behavior to what I need.

However, it took some effort to discover this option. I believe it would greatly benefit the community if we could clarify this usage in the migration guide and the field validator documentation. To contribute, I will be happy to create a quick PR to update the doc.

Thanks again.

### Example Code
The following are the confusing parts:
- In the [migration guide](https://docs.pydantic.dev/latest/migration/#changes-to-validators), it says:
```
If you use the always=True keyword argument to a validator function, note that standard validators for the annotated type will also be applied even to defaults, not just the custom validators. For example, despite the fact that the validator below will never error, the following code raises a ValidationError:
```
but it never mentioned `how to` migrate to v2

- And in the [Field API doc](https://docs.pydantic.dev/latest/api/fields/#pydantic.fields.Field), it states:
```
Run validation that isn't only checking the existence of defaults. True by default.
```
The default value doesn't seem to be `True` since the behaviors of putting `True` or leaving it as "default" differ.


### Python, Pydantic & OS Version

```Text
pydantic version: 2.0.3
pydantic-core version: 2.3.0 release build profile
install path: ./.venv/lib/python3.10/site-packages/pydantic
python version: 3.10.11 (main, Feb 18 2023, 20:53:20) [Clang 14.0.0 (clang-1400.0.29.202)]
platform: macOS-13.4.1-arm64-arm-64bit
optional deps. installed: ['typing-extensions']
```
```


Selected Assignee: @samuelcolvin


Discussion:
Thanks @benbenbang for reporting this.

Happy to review a PR that improv the doc

Resolving patch:
diff --git a/pydantic/fields.py b/pydantic/fields.py
--- a/pydantic/fields.py
+++ b/pydantic/fields.py
@@ -701,6 +701,9 @@ def Field(  # noqa: C901
     Used to provide extra information about a field, either for the model schema or complex validation. Some arguments
     apply only to number fields (`int`, `float`, `Decimal`) and some apply only to `str`.
 
+    Note:
+        - Any `_Unset` objects will be replaced by the corresponding value defined in the `_DefaultValues` dictionary. If a key for the `_Unset` object is not found in the `_DefaultValues` dictionary, it will default to `None`
+
     Args:
         default: Default value if the field is not set.
         default_factory: A callable to generate the default value, such as :func:`~datetime.utcnow`.
@@ -717,7 +720,7 @@ def Field(  # noqa: C901
         discriminator: Field name for discriminating the type in a tagged union.
         json_schema_extra: Any additional JSON schema data for the schema property.
         frozen: Whether the field is frozen.
-        validate_default: Run validation that isn't only checking existence of defaults. `True` by default.
+        validate_default: Run validation that isn't only checking existence of defaults. This can be set to `True` or `False`. If not set, it defaults to `None`.
         repr: A boolean indicating whether to include the field in the `__repr__` output.
         init_var: Whether the field should be included in the constructor of the dataclass.
         kw_only: Whether the field should be a keyword-only argument in the constructor of the dataclass.


Test patch: