Fix types for event properties

[rachel-fenichel]

Describe the bug

Event code makes some unsafe assumptions about which properties will or won't exist on an event. Also, the types of some properties vary between event classes. This can cause type checking issues.

Additional context

Some examples I found while converting event classes to ES6 classes:

• type used to not be declared on Abstract. I've declared it, but it has to have type string|undefined and be set to undefined in the abstract class to not break existing tests. In the interest of touching the minimum amount of code during this conversion, I annotated it to make the tests pass.
• blockId is not declared on every type of event. On some events it's declared as a non-nullable string. On others it seems to be a nullable string. Event filtration code uses the blockId property as part of a hash, regardless of whether the class says it exists.
  • I can't fix this with Object.hasOwnProperty because I also need to look for inherited properties.
  • There isn't a common base class (other than Abstract) that I can cast to in the filtration code.

Next steps

• List all event properties that are being used inconsistently this way.
• Audit event properties to understand which are unsafely being used when they are null or undefined
• Update types on any properties with these issues, adding casts as needed.

[rachel-fenichel]

After discussion in #5928 :

• We probably are using type because we used to not have distinct classes for events.
• Instead of checking type, we can use instanceof. That also gets type narrowing without needing casts.
• Switching to instanceof means we need to use require instead of requireType for the event classes.
• That leads to circular dependencies.

[cpcallen]

Type predicates for event types (e.g. isBlockMove) were added in #8538 as an interim measure to encapsulate .type checking (and automate type narrowing) until the circular import issues that prevent use of instanceof can be solved.