* 5.0.3

* Update CHANGELOG.md

* Update CHANGELOG.md and change to major version

---------

Co-authored-by: github-actions <github-actions@github.com>
Co-authored-by: david0xd <david@timechaser.org>

This PR adds [JSON-RPC 2.0](https://www.jsonrpc.org/specification)-compliant notification handling for `JsonRpcEngine`.

- JSON-RPC notifications are defined as JSON-RPC request objects without an `id` property.
- A new constructor parameter, `notificationHandler`, is introduced. This parameter is a function that accepts JSON-RPC notification objects and returns `void | Promise<void>`.
- When `JsonRpcEngine.handle` is called, if a `notificationHandler` exists, any request objects duck-typed as notifications will be handled as such. This means that:
  - Validation errors that occur after duck-typing will be ignored. At the moment, this just means that no error will be thrown if the `method` field is not a string.
  - If basic validation succeeds, the notification object will be passed to the handler function without touching the middleware stack.
  - The response from `handle()` will be `undefined`.
  - No error will be returned or thrown, unless the notification handler itself throws or rejects.
    - Notification handlers should not throw or reject, and it is the implementer's responsibility to ensure that they do not.
- If `JsonRpcEngine.handle` is called and no `notificationHandler` exists, notifications will be treated just like requests. This is the current behavior.

This is a performance improvement as the latter is actually faster.

json-stable-stringify x 13,870 ops/sec ±0.72% (94 runs sampled)
safe-stable-stringify x 30,367 ops/sec ±0.39% (96 runs sampled)