Improve DOM Event serialization

[zepumph]

While working on https://github.com/phetsims/phet-io/issues/995, https://github.com/phetsims/phet-io/issues/1693 and especially https://github.com/phetsims/phet-io/issues/1720, @jessegreenberg, @samreid and I found that Input.deserializeDOMEvent wasn't supporting a field, relativeTarget, that was needed to support PhET-iO playback for Input.js

This issue is to try to improve on the serialization strategy of our DOMEvents. Right now there are a couple of problems:

• Silent fallback into default/falsey values if we aren't opting into setting a particular property.
• deserialization generally creates a window.Event, which doesn't necessarily support subtypes that may have usages of specific subtype API. Like for KeyboardEvent when adding a listener to keydown.

We thought that it may be nice to formalize the Event that we create in deserializeDOMEvent. We could make this a Proxy, such that if we access something that isn't in the white-list, it can fail loudly and we can catch it early.

The above solution will still only support us as long as we exercise behavior with PhET-iO playback enabled. As an extra step we could wrap all domEvents coming into scenery input with the same Proxy algorithm. Thus we will know immediately, in any brand, when we hit a case that PhET-iO playback wouldn't support. This could help build out our coverage.

[zepumph]

• [ ] Another thing to do for this issue. I think we should serialize Event.target back into an HTML element, and not into an object literal like it is now (which is what I did for relativeTarget in https://github.com/phetsims/phet-io/issues/1720). This is what it looks like now:

  if ( key === 'target' ) {
          domEvent[ TARGET_SUBSTITUTE_KEY ] = eventObject[ key ];
        }

[zepumph]

Even without Proxy, I think that the Event constructor could take much with options instead of trying to mutate after construction.