this commit updates stencil to create nodes in the typescript syntax
tree using `ts.factory.*` functions, rather than the (create|update|etc.)
functions that were originally exported directly on `ts`. said functions
were deprecated in v4.0 of typescript, and are slated to be removed in
v5.0.

this commit has two motivations.
1. these functions will be removed in typescript 5.0. this is a piece of
   technical debt the team was going to be tackling in preparation for
   said upgrade.
2. when attempting to upgrade to typescript 4.8, we ran into two issues:
   - several warnings regarding the use of these deprecated methods
     began to spring up, which wasn't a pleasant dev experience
   - it broke stencil - static members were not being properly
     transpiled from the original source code to our intermediate
     representations. code that was originally written as:
```tsx
@component({ ... }) export class Foo {
  @prop bar: boolean;
}
```
    would be transformed to:
```tsx
export class {}
```

the changes in this PR help with the 4.8 upgrade, in that moving to
functions that are no longer deprecated allow for the code to be
transpile properly. in TS 4.8, decorators are no longer a separate field
on `Node` derived classes, but are added to the `modifiers` field. this
change does _not_ take those changes directly into account. it only
moves to the non-deprecated factory functions. the upgrade to TS 4.8
will modify some of these functions calls to manage `Node` typing
changes

Two changes were necessary to remove a circular dependency relationship
between `bundle-output.ts` and `dev-module.ts`:

- two constants are moved to a new file, `constants.ts`
- functionality relating to resolving node module IDs is moved to a new
  file (`dev-node-module-resolve.ts`)

This turns the `strictFunctionTypes` compiler flag on and fixes the
errors uncovered by doing so.

this commit applies #3766 (comment),
which was missed prior to merging the pull request

Bumps [@types/semver](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/semver) from 7.3.12 to 7.3.13.
- [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases)
- [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/semver)

---
updated-dependencies:
- dependency-name: "@types/semver"
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Bumps [@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node) from 16.18.0 to 16.18.2.
- [Release notes](https://github.com/DefinitelyTyped/DefinitelyTyped/releases)
- [Commits](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node)

---
updated-dependencies:
- dependency-name: "@types/node"
  dependency-type: direct:development
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Ryan Waskiewicz <ryanwaskiewicz@gmail.com>

…ors (#3776)

This change ensures that statements in an existing constructor are not
thrown on the floor in the case that we need to edit a constructor (i.e.
when there is a field with `@Prop` that we need to initialize in the
constructor).

In f977830 we made a change to
initialize any class fields decorated with `@Prop()` in a constructor.
The code to do this would look for a constructor on the class and, if
found, update the body of the constructor with statements to initialize
the field.

Unfortunately, that commit would drop all existing statements in the
constructor on the floor! This broke how some Stencil users initialize
fields or do certain side effects, since no code they wrote in their
constructors would make it through to the built output.

This commit fixes the issue by instead setting the constructor body to
be all of our newly created statements followed by any existing
statements. This will allow users to initialize fields to custom values
in the constructor if they so chose.

See #3773 for an issue describing the issue.