fix(fast-element): every third subscriber not registered

[EisenbergEffect]

Description

Fixes a bug that occurred any time the 3rd subscriber was added to an observer.

Motivation & context

The SubscriberSet has internal optimizations that track the first two subscribers in fields, so it can avoid creating and pushing into an array for the most common scenarios. However, when the 3rd subscriber is added, it switches to an array, transferring the first two subscribers as part of that process. Then all future subscriptions just push into the array. The issue is that during that switch from fields to arrays, the 3rd subscription that triggered the process was not added to the array.

This PR fixes the above issue but also:

• Adds 160 unit tests for breadth and depth testing of SubscriberSet and PropertyChangeNotifier. Some looping was used to generate more tests than were manually written, in order to test different numbers of subscribers, since the above bug would not be caught by a simple set of breadth-based tests.
• Stabilizes all APIs related to the notification core. This includes renaming SubscriberCollection to SubscriberSet which more accurately represents its behavior. This also involved adding a has method to the set, so that the presence of a subscriber could be checked. Finally both SubscriberSet and PropertyChangeNotifier now keep track of the source object they are providing notifications for, so that it doesn't need to be passed in from the outside on notification (which seemed odd and non-ergonomic).
• Adds API documentation to all notification-related APIs.
• Fixes a number of issues with karma and yarn-hoisted dependencies which caused the browser-based tests to fail.
• Fixes an issue with the browser-based test command that caused it not to detect all tests.
• Fixes an issue with the rollup cache that caused builds to fail on some dev machines.

Note: I turned linting off on the new test file. This is because I couldn't get the rules to match the scenarios and trying to match the code to the rules just created a test mess, with much less readable and more painful code. We should revisit this in the near future.

Issue type checklist

• Chore: A change that does not impact distributed packages.
• Bug fix: A change that fixes an issue, link to the issue above.
• New feature: A change that adds functionality.

Is this a breaking change?

This is technically a breaking change to the notifier APIs, but it is unlikely to affect anyone.

Process & policy checklist

• I have added tests for my changes. 🎊
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

[chrisdholt]

So good to see tests coming in! What an odd issue, great to see this resolved quickly. Thanks @EisenbergEffect for resolving and @marjonlynch for finding this!