Fixes peerjs issue 715

When serializing an object that contains `undefined` as a value,
the current packer code incorrectly serializes the value as `null`
(0xc0). `null` and `undefined` are not the same thing, and should
not be serialized into the same binary representation.

Strangely, the unpacker actually does support unpacking `undefined`
values using the binary representation 0xc1.

There was an old pull request (#4) that seems to address this along
with a bunch of other seemingly unrelated changes. The GitHub UI
seems to think that the PR was merged manually, but the code that
fixes this issue never actually made it into the master branch as
far as I can tell.

Another option is to omit any keys with `undefined` values. This is
what `JSON.stringify` does as `JSON` does not support `undefined`
natively. When deserialized, the semantics are mostly correct, as
accessing a key that doesn't exist will give you `undefined`. This
is slightly more efficient, I suppose and maintain the exact same
behavior between binarypack and JSON serialization which is a good
thing. However, you can observe the difference with `Object.keys`,
`Object.hasOwnProperty`, etc.

The code was assuming that they had UTF-8 length 6 instead of 4, causing
a crash on any character above U+FFFF.

Also handle unpaired surrogates correctly.

pack_string / unpack_string: handle chars above U+FFFF

npm WARN old lockfile
npm WARN old lockfile The package-lock.json file was created with an old version of npm,
npm WARN old lockfile so supplemental metadata must be fetched from the registry.
npm WARN old lockfile
npm WARN old lockfile This is a one-time fix-up, please be patient...
npm WARN old lockfile

refactor: typescript strict mode compliant

Githubs runners are slow

* Add renovate.json

* ci: configure renovate

---------

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Jonas Gloning <[email protected]>

new implementation is much faster

Changing the encoding of `undefined` is a breaking change. 
I am postponing this so we can bundle this with other breaking changes.
It’s still a good idea to change this eventually.

This reverts commit 83af274.

ad70153 was not recognized by semantic-release

BREAKING CHANGE: Return type of `pack` is now `ArrayBuffer`

Semantic-release touches this file during release.

Welcome to [Mend Bolt for
GitHub](https://github.com/apps/mend-bolt-for-github) (formerly
WhiteSource). This is an onboarding PR to help you understand and
configure settings before Mend starts scanning your repository for
security vulnerabilities.

:vertical_traffic_light: Mend Bolt for GitHub will start scanning your
repository only once you merge this Pull Request. To disable Mend Bolt
for GitHub, simply close this Pull Request.



---

### What to Expect

This PR contains a '.whitesource' configuration file which can be
customized to your needs. If no changes were applied to this file, Mend
Bolt for GitHub will use the default configuration.

Before merging this PR, Make sure the [Issues tab is
enabled](https://docs.mend.io/bundle/community_tools/page/enabling_the__issues__tab_for_the_github_repository.html).
Once you merge this PR, Mend Bolt for GitHub will scan your repository
and create a GitHub Issue for every vulnerability detected in your
repository.

If you do not want a GitHub Issue to be created for each detected
vulnerability, you can edit the '.whitesource' file and set the
'minSeverityLevel' parameter to 'NONE'.

---

:question: Got questions? Check out Mend Bolt for GitHub
[docs](https://docs.mend.io/bundle/community_tools/page/mend_bolt_for_github.html).
If you need any further assistance then you can also [request help
here](https://whitesourcesoftware.force.com/CustomerCommunity/s).<!--
<WHITESOURCE>{ "installationId": "34705231"}</WHITESOURCE> -->

Co-authored-by: mend-bolt-for-github[bot] <42819689+mend-bolt-for-github[bot]@users.noreply.github.com>

….57.0

….57.1

….58.0

….59.0

….59.1

….59.2

….59.5

….59.6

….59.7

….59.8

….59.9

This reverts commit 6cd23f5.

….59.11

….60.0