…, deprecate `toHaveErrorMessage` (#503)

* fix: Conform `toHaveErrorMessage` to Spec and Rename

Included Changes:
- According to the WAI-ARIA spec, passing an invalid
  `id` to `aria-errormessage` now fails assertion.
  This means that any empty spaces inside
  `aria-errormessage` will now cause test failures.

- According to the WAI-ARIA spec, developers can now
  assert that an accessible error message is missing
  if `aria-invalid` is `false` (or if the
  `aria-errormessage` attribute is invalid).

- Updated the error message and test cases surrounding
  the requirement for `aria-invalid`. They are now
  more detailed/accurate.

- Renamed `toHaveErrorMessage` to
  `toHaveAccessibleErrorMessage` to be consistent with
  the other a11y-related methods (`toHaveAccessibleName`
  and `toHaveAccessibleDescription`).
   - Note: This deprecates the previous
   `toHaveErrorMessage` method.

- Updated documentation. Similar to the
  `toHaveAccessibleDescription` method, this description
  is much more lean, as the reader can simply read the
  WAI ARIA spec for additional details/requirements.

* refactor: Simplify Exports from `matchers.js`

This makes the code easier to maintain as more
exports are added.

* feat!: local types, supporting jest, @jest/globals, vitest

Moves matcher types back into this package and adds support for
@jest/globals and vitest.

BREAKING CHANGE: Removes the extend-expect script. Users should use
the default import path or one of the new test platform-specific
paths to automatically extend the appropriate "expect" instance.

extend-expect was not documented in the Readme, so this change should
have minimal impact.

Users can now use the following import paths to automatically extend
"expect" for their chosen test platform:

- @testing-library/jest-dom - jest (@types/jest)
- @testing-library/jest-dom/jest-globals - @jest/globals
- @testing-library/jest-dom/vitest - vitest

For example:

import '@testing-library/jest-dom/jest-globals'

Importing from one of the above paths will augment the appropriate
matcher interface for the given test platform, assuming the import
is done in a .ts file that is included in the user's tsconfig.json.

It's also (still) possible to import the matchers directly without
side effects:

import * as matchers from '@testing-library/jest-dom/matchers'

* Update kcd-scripts

BREAKING CHANGE: Drop node < 14

* fix: matchers type is making the global expect unsafe

* Add test file for TypeScript typings

* Remove jest specifics from matchers.d.ts

* Type tests for all test environments

* Fix all AsymmetricMatcher interfaces

* Ignore type tests from eslint

---------

Co-authored-by: Michael Manzinger <[email protected]>
Co-authored-by: John Gozde <[email protected]>

* Add rollup config

* Sort dependencies in package.json

* Clean output folder before build

* Use relative paths for entries

* Convert cjs to esm if needed

* Add extensions to lodash imports

To support node16 resolution

* Ignore coverage for vitest and jest-globals

…532)