Permit multiple data subscriptions per original topic

[acruikshank]

closes #126

Motivation

When we add new data topics, we would map the block topic to a response topic on the subscriber. It is possible for multiple blocks to go out in one response, however, so the subscriptions would overwrite each other.

This PR first refactors the subscription system to remove the concept of mapping and replace it with the concept of data topics. It then modifies the subscriber to permit multiple data subscribers per topic and ensure that each of these data subscribers is notified when a topic event is published.

Proposed Changes

1. Eliminate the MappableSubscriber interface because there only needs to be one implementation.
2. Introduce TopicData to slightly distinguish data subscriptions from the original topic subscription. This replaces the mappable topic.
3. Rename notifications.SubscribeOn to notifications.SubscribeWithData for clarity.
4. Rename mappable.go to data_subscriber.go and rename mappableSubscriber to TopicDataSubscriber.
5. Replace Notifee's topic with a data field of type TopicData.
6. Replace mappableSubscriber's idMap with TopicDataSubscriber's data which is now a map of topics to multiple TopicDatas.
7. DataSubscriber's OnNext and and OnClose now call the corresponding methods on the internal subscriber once for each TopicData mapped to the original topic. This fixes block sent listener is not called for every block sent #126.
8. Add a test that a listener registered with RegisterBlockSentListener will get called once for every block actually sent (i.e. that block sent listener is not called for every block sent #126 has been fixed). This test failed before the last two changes.

cc @dirkmc

[welcome]

Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

• The context for this PR is clear, with relevant discussion, decisions
  and stakeholders linked/mentioned.

• Your contribution itself is clear (code comments, self-review for the
  rest) and in its best form. Follow the code contribution
  guidelines
  if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

• A maintainer will triage and assign priority to this PR, commenting on
  any missing things and potentially assigning a reviewer for high
  priority items.

• The PR gets reviews, discussed and approvals as needed.

• The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

[dirkmc]

Looks great! 👍

[dirkmc]

Confirmed that this fixes the go-data-transfer test TestDataSentEvents