feat(VForm): add reactive errorMessages

[Surof1n]

Description

This PR adds a reactivity for errors. This change helps to make error messages more flexible.

Motivation and Context

This will help solve the problem if the developer needs to render errors or use them at the time of the actual occurrence, and not at the time of full form validation.

How Has This Been Tested?

add e2e test

Markup:

<template>
  <v-app>
    <v-container>
      <v-form ref="form" v-model="isValid">
        <template #default="{ errorMessages }">
          <v-text-field
            v-model="name1"
            :max-errors="2"
            required
            :rules="[(v) => !!v || 'Error 1']"
            class="mb-2"
            label="Label 3"
            variant="underlined"
            single-line
          />
          <v-text-field
            v-model="name2"
            :max-errors="2"
            required
            :rules="[(v) => !!v || 'Error 2']"
            class="mb-2"
            label="Label 3"
            variant="underlined"
            single-line
          />
          <v-text-field
            v-model="name3"
            :max-errors="2"
            required
            :rules="[(v) => !!v || 'Error 3']"
            class="mb-2"
            label="Label 3"
            variant="underlined"
            single-line
          />
          <div class="errors">
            {{ errorMessages }}
          </div>
          <div>valid status: {{isValid}}</div>
        </template>
      </v-form>
    </v-container>
  </v-app>
</template>

<script>
  export default {
    name: 'Playground',
    data () {
      return {
        isValid: false,
        name1: '',
        name2: '',
        name3: '',
        menu: false,
      }
    },
  }
</script>

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Improvement/refactoring (non-breaking change that doesn't add any features but makes things better)

Checklist:

• The PR title is no longer than 64 characters.
• The PR is submitted to the correct branch (master for bug fixes and documentation updates, dev for new features and backwards compatible changes and next for non-backwards compatible changes).
• My code follows the code style of this project.
• I've added relevant changes to the documentation (applies to new features and breaking changes in core library)

[Surof1n]

@KaelWD Sorry, maybe run a PR workflow, thanks!

[KaelWD]

Please don't reformat files like that

[KaelWD]

Is this supposed to be like v2's lazyValidation, which seems to not be implemented yet?

[Surof1n]

Please don't reformat files like that

ok, this need change?

[Surof1n]

Is this supposed to be like v2's lazyValidation, which seems to not be implemented yet?

I read the lazyValidation functionality, my changes are not very similar to this, I described in the motivation for what I needed it.

[nekosaur]

Do we not want errorMessages to always reflect current state?

[Surof1n]

Do we not want errorMessages to always reflect current state?

When I was developing, I ran into a problem that I only receive error messages at the time of form validation, I decided that it would be worthwhile to leave the old behavior and add some prop for it and create a situation where errorMessages appeared after the form elements were validated.