Fixed the ReactionSpec type fix

[jskupsik]

Hoist P/R Checklist

Pull request authors: Review and check off the below. Items that do not apply can also be
checked off to indicate they have been considered. If unclear if a step is relevant, please leave
unchecked and note in comments.

• Caught up with develop branch as of last change.
• Added CHANGELOG entry, or determined not required.
• Reviewed for breaking changes, added breaking-change label + CHANGELOG if so.
• Updated doc comments / prop-types, or determined not required.
• Reviewed and tested on Mobile, or determined not required.
• Created Toolbox branch / PR, or determined not required.

If your change is still a WIP, please use the "Create draft pull request" option in the split
button below to indicate it is not ready yet for a final review.

Pull request reviewers: when merging this P/R, please consider using a squash commit to
collapse multiple intermediate commits into a single commit representing the overall feature
change. This helps keep the commit log clean and easy to scan across releases. PRs containing a
single commit should be rebased when possible.

[jskupsik]

My original PR ended up not changing the ReactionSpec.equals type.

The derived type ended up being IEqualsComparer<T> & (keyof typeof comparer | IEqualsComparer<T>) which simplifies down to IEqualsComparer<T> - which is exactly what it was before my change.

The issue is that ReactionSpec does not extend IReactionOptions in the typescript sense. The fact that it accepts values for equals that IReactionOptions does not accept breaks inheritance- a ReactionSpec may not work if used as a IReactionOptions. We understand that and use the private parseReactionOptions() function to convert the ReactionSpec to IReactionOptions.

The type needs to be more explicit about this lack of inheritance - "ReactionSpec is mostly of type 'IReactionOptions' EXCEPT for the 'equals' property, which we override and then handle ourselves."

[lbwexler]

So interesting -- I almost suggested the use of omit for the last go around, but had thought in my research that the & would override the type. In any case, looks good to me. I would probably make this interface rather than a type