Enhance remote flow sources for CAP

[knewbury01]

New approach

This PR refactors the remoteflowsource types to a simpler type that captures explicit known exposed service handlers OR general event handlers that are registered but not necessarily tied to services

This PR also enhances unit tests for the different ways that handlers can be specified

Old (deprecated) approach

this PR aims to address the following previously missing scenarios:

• CDS compiles fail and therefore JS event handlers are paired to unknown CDS entities
• the event handler is registered as an every service handler (example this.on ('UPDATE', '*', req => {...}))

specifically the PR:

• adds test cases to cover cap event handler registrations that were previously missing in the scenarios listed above
• add remote flow source type to cover the listed cases of event handler registration

the current approach enumerates over service + event handler pairing cases and follows closely with the previous technique of adding remote flow sources as event handler request objects

an alternative potential approach would be to consider making ServiceInstance more responsible for its event handler registration (if we can assume that all/base service types may have event handlers) and then make their request object params exposed on the implementing types (and still extend RemoteFlowSource)
this approach may be more assured to cover all ways of specifying services and their handlers/looks more generic
But may not make sense if many implementing types are redundant or do not indeed allow event handler registration

[jeongsoolee09]

First round of review.

[jeongsoolee09]

Two more minor points to go!

[jeongsoolee09]

Looks good! Thanks for your work!