Fix types resolution when importing jest types from @jest/globals

[mulekick]

Summary

This pull request contains :

1. An additional module declaration that adds support for expect-puppeteer matchers types resolution when jest types are imported from @jest/globals (issue 601).
2. As a result, installing @types/jest is no longer mandatory and the project is now 100% compliant to jest official recommendations.
3. Edits of the main README and the jest-environment-puppeteer README to describe how to set up with typescript in a more detailed way.
4. An edit of the expect-puppeteer README to adhere to the current API and point to the new puppeteer docs.
5. Removals of the expect-puppeteer imports in the test files that do not use expect.
6. A few upgrades of deprecated methods on the puppeteer API (see toClick.ts).

Note : due to the way typescript resolves modules, the community-provided types for jest-puppeteer will be prevalent if still installed despite being outdated. As a result, I've added a note in the README to recommend uninstalling them when upgrading to >=10.1.2.

Test plan

1. No breaking changes or regressions should occur since the implementation was left untouched, only types declarations were changed. Note though that a (breaking?) change was introduced in 10.1.2 since the types resolution for the jest-environment-puppeteer globals requires importing jest-puppeteer explicitly when not using the deprecated pre v8.0.0 types. As a result, I don't know if it commends a new minor let major version since it only affects the DX, but I think it's worthy of mentioning.

2. Test suite passes 100%.

3. When testing the minimal repo with the following dependencies (notice that @types/jest is not installed) :

4. Typescript complains, types resolution does not work

5. Then changing dependencies to point to my fork and npm i :

6. Typescript is ok and types resolution works again 👍

7. I've also tested that types resolution works the same way when reinstalling @types/jest.