Move ResolveSubscriberSpec out of the Subscription Controller

[Harwayne]

From #866 (review):

Minor optional suggestion: move ResolveSubscriberSpec to another package if other controllers will be using it. That makes its intended use as a generic helper method more clear to future maintainers.

ResolveSubscriberSpec is currently a method in the Subscription Controller, but is used by multiple controllers (Subscription and Trigger for now). As it is used by multiple controllers, it should be moved out of the existing location and into a more generic one.

[markfisher]

Should Trigger have a "subscriber"? Obviously a Subscription has a subscriber, but for a Trigger it seems like it should be different terminology so as not to blur the lines between eventing and messaging. In the Trigger case, it's not subscribing to a specific destination but instead "observing" or "listening" to events based on a filter, so it could be an "observer" or "listener" (or "handler") for the events that match its selection criteria. A subscription is typically based on a destination (Channel, Topic, etc).

[Harwayne]

Regardless of what it is called on each side, both eventing and messaging have a need to determine a concrete URL given an ObjectReference to an Addressable or K8s Service. That logic should be moved out of its current location in the Subscription Controller into a more generic location.

[markfisher]

I can see the point in having shareable logic for "resolveObjectReferencetoURL", but that's different than sharing at the level of the "Subscriber" terminology.