feat(e2e): add support for puppteer v19 (#3810)

this commit adds support for puppeteer v19. it is added to the stencil
v3.0.0 development branch, as puppeteer v14 no longer supports node
v12, which stencil v2 still does.

each section below describes the work done for each version of puppeteer.

# Puppeteer v11, v12, v13

v11, v12, v13 all did not require any changes to the stencil codebase.

# Puppeteer v14

the package is now declared in `package.json` using a caret ("^")
instead of a tilde ("~"). the author (rwaskiewicz) was being cautious
at the time when making the change to support v10 of stencil in
#2934, to a degree that is no
longer necessary (it their early days on Stencil, and was being
conservative)

v14 of puppeteer introduced private fields in their source code. this
affected stencil's validation scripts for type declaration files, as
the default settings would create a TypeScript `program` that could not
be properly compiled/validated.

the `moduleResolution` and `target` fields needed to be explicitly
set to allow the transpiled `.d.ts` to pass validation. this is a result
of cascading defaults where for the `createProgram` call:
- the `target` field defaults to "ES3"
- the `target` default causes the `module` field to default to
  "CommonJS"
- the `module` default causes `moduleResolution` to default to
  "classic", which can't resolve the new type declaration file. as a
  result, we explicitly set this field
- the `target` field is set to support the private identifiers in
  puppeteer

# Puppeteer v15

this commit increments the supported version of puppeteer from v14 to
v15.

starting with puppeteer v15, the library performs type
inference/deduction for the `evaluate()` function. this commit updates
the types (often removing them) at the advice spelled out in
puppeteer/puppeteer#8547.

# Puppeteer v16

v16 did not require any changes in the codebase.

# Puppeteer v17

puppeteer v17 made accessing a puppeteer `ExecutionContext`, an entity
used to run javascript, an internal entity. previously, stencil would
directly access retrieve an `ExecutionContext` from a helper function
that is no longer exposed. to work around this in puppeteer v17+, two
different strategies for getting access to this entity have been added.
Each strategy is dependent on how we were previously accessing the
`ExecutionContext`.

  1. `ElementHandle` Scenario

  in this scenario, an `ExecutionContext` was being pulled off an
  `ElementHandle` instance.

  the suggested way of getting an `ExecutionContext` in puppeteer v17+ for
  an `ElementHandle` is through the `frame` getter on the `ElementHandle`
  instance. doing so does not work in puppeteer v16 and below. for those
  versions of puppeteer v16 and below, stencil will default to the original
  `executionContext()` behavior. otherwise, the return value of the
  `frame` getter is returned from a new utility method.

  in order to determine which version of puppeteer is used, a mechanism
  for reading the puppeteer `package.json#version` field has been added.
  this avoids clunky prototype lookups that have been used in the past,
  and are not always the safest way to detect the version of puppeteer
  being used (e.g. a field may exist on the prototype chain of an object
  in 2 different versions of puppeteer, but do very different things).

  2. `JSHandle` Scenario

  accessing a `JSHandle`'s `ExecutionContext` is necessary in
  `puppeteer-event.ts`. because this is the only instance where stencil
  would get an `ExecutionContext` from a `JSHandle`, no utility function
  for retrieving an `ExecutionContext` was created. rather, the same
  effect can be achieved in a backwards compatible way by calling
  `evaluate()` directly on the `JSHandle` instance.

  we do not call `.asElement()` on the `JSHandle` instance and
  subsequently use the "`ElementHandle` Scenario" described above as a
  `JSHandle` does not always have an element associated with it, making it
  impossible to get an `ExecutionContext` in such instances

# Puppeteer v18

puppeteer v18 did not include any breaking changes that required major
breaking changes to stencil

# Puppeteer v19

puppeteer v19 did not include any breaking changes that required major
breaking changes to stencil

# Node, NPM versions

this pr increments the versions of node & npm used to run our karma tests.
the newest version of puppeteer requires use to upgrade these. consumers
of stencil and puppeteer should refer to the puppeteer breaking changes
guides (owned by the puppeteer team) to verify they are using the correct
minimum versions of node/npm

BREAKING_CHANGES.md

@@ -30,7 +30,7 @@ This is a comprehensive list of the breaking changes introduced in the major ver
   * [Flag Parsing, `parseFlags()`](#flag-parsing-parseflags)
   * [Destroy Callback, `addDestroy()`, `removeDestroy()`](#destroy-callback-adddestroy-removedestroy)
 * [End-to-End Testing](#end-to-end-testing)
-  * [Puppeteer v10 Required](#puppeteer-v10-required)
+  * [Puppeteer v10+ Required](#puppeteer-v10-required)
 
 ### General
 #### New Configuration Defaults
@@ -267,15 +267,18 @@ Replace all instances of `addDestory` with `addDestroy` and all instances of `re
 The functionality of these methods remains the same.
 
 ### End-to-End Testing
-#### Puppeteer v10 Required
+#### Puppeteer v10+ Required
 Versions of Puppeteer prior to Puppeteer version 10 are no longer supported.
 In newer versions of Puppeteer, the library provides its own types, making `@types/puppeteer` no longer necessary.
-Ensure that Puppeteer v10 is installed, and that its typings are not:
+Ensure that Puppeteer v10 or higher is installed, and that its typings are not:
 ```bash
-$ npm install puppeteer@10
+$ npm install puppeteer
 $ npm uninstall @types/puppeteer
 ```
 
+To see which versions of Puppeteer are supported by Stencil, please see our [support matrix](https://stenciljs.com/docs/support-policy#puppeteer)
+
+
 *****
 
 ## Stencil Two