When re-creating listeners in EVMConnect/EthConnect/FabConnect use the last event block

[peterbroadhurst]

See #1531

Every time Core starts, it confirms all the listeners exist that it needs for all of:

• Contract listeners registered by applications
• BatchPin listeners for any multi-party namespaces
• Token listeners - indirectly via /activatepool
  • Not changed in this PR - see #1531 comments for justification

This is needed for two cases:

1. In case the listeners were deleted operationally for any reason (intentionally or otherwise) - such as a DR scenario
2. In the v1.2->v1.3 migration, where we intentionally orphan all the core-wide listeners in favor of namespace-specific ones

In both of these cases, the logic was naive for the newest/latest case - where it treats "now" as the latest event.

That is a problem, as it might be a long time since the original listener was created, and it might have delivered many events already. In which case there might be "gaps" we skip over between the last event detected by the old listener, and the first event we detect on the new one.

This PR closes that window, by looking at the protocolId of the last event - which is architecturally required to be a lexicographically sorted string identifying the position of the event on the blockchain.

If there's been a previous event, that's used by the blockchain connector as the fromBlock for the new listener.

Also, if "oldest" or an explicit block number is used, and the block number is before the block determined by the above process, then the newer block is used.