ensure that sourceMapUrls are compliant with RFC-3986, per the sourcemap
[specification](https://sourcemaps.info/spec.html#h.crcf4lqeivt8):

> Note: <url> is a URL as defined in RFC3986; in particular, characters
outside the set permitted to appear in URIs must be percent-encoded.

STENCIL-173: Make sourceMapUrl values RFC 3986 compliant

update typescript to v4.3.5

add type annotations to methods that have an implicit any type in TS 4.3 - for more information, see microsoft/TypeScript#26623

map TS 4.3+ `JSDocTagInfo` to `CompilerJsDocTagInfo` - for more information, see microsoft/TypeScript#43312

add type guard for `TestingSystem`. in TS 4.3, `Object.defineProperties` is now generic, and returns the same type `T` as it's first argument. adding a typeguard allows consumers of this method to ensure they're receiving a `TestingSystem` object

enable `noImplicitOverride` compiler flag

alias `npm run build` to `npm run build.prod` to ensure the
`scripts/` dir is always compiled. the alias ensures there are
no breaking changes with this quick change.

this commit enables sourcemaps for the cli/ directory of Stencil. 
this commit does not enable sourcemaps for all parts of the 
repository. these sourcemaps differ from the ones that exist 
today in that they are sourcemaps for the compiler itself, and are
primarily to be used by the Stencil team/anyone hacking on the
compiler.

this commit also sets up the base configuration that will be required to
enable sourcemaps across the entire project:
- updates to CONTRIBUTING.md that explains how to run a debugger in two
  IDEs
- launch configurations for the debugger for VS Code
- enabling sourcemaps in the project's `tsconfig.json` file
- the addition of the rollup-plugin-sourcemaps package. this will be
  used in subsequent commits to take the sourcemaps generated by
  TypeScript and propagate them through the bundling process via rollup

update the 'old' ISSUE_TEMPLATE.md file to ensure we get similar
information to the one that uses GitHub's V2 Issues templates (currently
in beta).

this file was updated rather than removed because users can still reach
it in the GitHub UI under the 'Issues' tab, where GitHub currently
provides a "Don't see your issue here? Open a Blank Issue" link that
opens this file.  this file will be deprecated/removed once GitHub
removes that call to action.

…3106)

this commit fixes a very specific issue, where reflected props may lead
to unnecessary re-renders. in order to trigger the issue, each of the
following conditions must be met:

1. the lazy load build of stencil is used
2. a prop in a stencil component is created
  2.1. the prop is created with `{reflect: true}`
  2.2. the member is a complex type, such as `number | any`. types such as
    `number` and `number | number` will not trigger the error. using the
    optional token following the member's name will not create a complex
    type for the purposes of this bug (e.g. `@Prop() val?: number`)
3. the stencil component containing the prop must have a `render` fn
4. the value passed to the component must not be a string. this implies
   that the component cannot be rendered directly within an html file,
   as the prop will be converted to a DOMString implicitly

when the conditions above are met, the problem will manifest itself as a
warning in the console when running in developer mode:

```
The state/prop "PROP_NAME" changed during rendering. This can
potentially lead to infinite-loops and other bugs"
Element <my-component val="1" class="hydrated>...</my-component>
New value 1
Old value 1
```

what is happening under the hood is the component containing the prop
will be rendered by stencil. stencil will then attempt to reflect the
prop back to the attribute on the component's element via a call to
`setAttribute(elm, val)`. `setAttribute` implicitly converts the val
provided as the second argument to a DOMString, which is then converted
to a JavaScript string.

invoking `setAttribute` initiates `attributeChangedCallback` being called on
the component, using the aforementioned string value.
`attributeChangedCallback` leads to a series of `set*` calls internally
before using the string representation of the prop, even when a number
is passed like so:

```tsx
<my-component my-prop={1}></my-component>
```

the reason for this is that when doing change detection on prop values,
stencil performs strict equality matching on the new value against an
older known value (outside the context of `attributeChangedCallback`)
using the `===` operator.

with this change, we attempt to detect a case of accidental type
coercion to a DOMString for the same value. within
`attributeChangedCallback`, the prop may be looked up on the prototype
of the constructor of the proxy component. If the prop is found on the
prototype, is of type number, and the string received matches the
number, the change is discarded.

attempts to match the string against other primitives such as boolean,
null, and undefined have been intentionally avoided for this commit for
simplicity:
- boolean attributes are considered `true` if they are present and their
  value is the emtpy string or the attribute's name
- null is traditionally sets the value to the string 'null', rather than
  nullifying or removing the value

this commit fixes up small issues that are inconsequential to the
implementation of this fix, but were found during the debugging 
process. they are listed below:
- removing an unused tslint:disable pragma
- fixing typos
- adding curly braces where needed
- simplifying a ternary expression

this commit allows `delegatesFocus` to be properly applied to components
generated using the following output targets:
- dist-custom-elements
- dist-custom-elements-bundle

the generation of the `attachShadow` call is moved from a standalone
function to being attached to the prototype of the custom element when
we proxy it. the reason for this is that we need the component metadata
to to determine whether or not each individual component should have
delegateFocus enabled or not.

this led to the removal of the original standalone attachShadow
function. I do not consider this to be a breaking change, as we don't
publicly state our runtime APIs are available for general consumption.

this change also led to the transition from using ts.create*() calls to
ts.factory.create*() calls for nativeAttachShadowStatement, which is the
general direction I'd like to take such calls, since the former is now
deprecated

STENCIL-90: "dist-custom-elements-bundle" does not set delegatesFocus
when attaching shadow

in #3065, [this change](https://github.com/ionic-team/stencil/pull/3065/files#diff-331c8328fdb955860d22bfba1d1aa6921afd770dc47256c7bb5114fa997e38edR131)
URI encodes the title that gets added to our github release notes. after
running it for the v2.9.0 release, I found that this was being _double_
encoded. this commit reverts the encodeURIComponent call to ensure the
title appears properly in github

add a step to the release steps/playbook to sync 'next' branches of
stencil following a release off of the main branch

remove the unnecessary build.prod script. this commit is a
cleanup/follow on from #3109

switch the value of the `incremental` flag in `scripts/tsconfig.json` to
false. when using incremental builds, typescript does not check the
output directory to see whether or not a file that would be emitted
exists or not. this can lead to cases where deleting a file may cause it
to be re-emitted when running compile again. this incurs a ~3 
second increase in build time, but will always ensure that the output
is up to date.

refactor scripts/index.js to attempt to recompile scripts in case
require() fails as a last ditch effort to recompile/require the module
should the `--prepare` flag not be passed in during invocation

update the package.json build script to always recompile scripts/ using
the `--prepare` flag. this allows us to remove the tsc.scripts
invocation, since they effectively do the same thing

create clean scripts in package.json for removing artifacts that are
generated during the build process