feat: add support for observables to withDataService

[michael-small]

This PR would close issue 85: suggestion/question: withDataService support for Observables

What was done

• The interface for the implementing services that use withDataService was expanded to take Observable methods
  • type PromiseOrObservable<Entity> = Promise<Entity> | Observable<Entity>;
  • ex) loadById(id: EntityId): PromiseOrObservable<Entity>;
    • Existing functionality supports something like this
      • loadById(id: EntityId): Promise<Flight> {...}
    • These changes would now also support something like this
      • loadById(id: EntityId): Observable<Flight> {...}
• The withDataService methods were adapted to take an observable (returns a subscription) as well as already taking promises
  • type PromiseOrSubscription<Entity> = Promise<Entity> | Subscription;
  • ex) [K in Collection as `load${Capitalize<K>}Entities`]: () => PromiseOrSubscription<void>;
    • The method checks if something is an instance of an observable. If so, the method manually pipes and subscribes. If not, the method resolves the call as a promise.

edit:
What was chosen not to be done, as per talk in the issue

• For the moment, rxMethod is not used. The solution currently just manually subscribes. Supporting rxMethod would widen the feature to need to take non-static values such as signals or observables.
  • "I'd say for the first version, it should be fine of you check if the response is of type Promise or Observable. I guess you would do an automatic subscribe. If there's demand, we can later maybe add the rxMethod and map a Promise to an Observable." - Rainer

What is left to be done (before turning from Draft PR to regular PR)

• Tests for both the promises and observables
  • There are not already existing tests for withDataService as is with promises, so I should probably make those first and get those in as a PR before moving onto this one. Thoughts?
    • edit: See the next PR: test(dataService): add basic tests for withDataService #89
  • Observable tests should follow
  • I am admittedly not very experienced/good at testing, so testing is probably the main hurdle now that implementation is hopefully all good apart from iteration on feedback.
• Explicitly handle unsubscribing
  • HTTP observables tend to be considered self handling observables if I understand correctly, but it would be good to unsubscribe anyways
  • Pass in an optional DestroyRef? Otherwise basic take(1) or first or something?

[michael-small]

I forgot to actually push up the usage of the RXJS equivalent service and point that service at the right endpoint... fixed 47fc853