IgxSelectionAPIService should be provided on a component level

[teodosiah]

Related to #13923
IgxSelectionAPIService should be provided on a component level instead of on a root level

[damyanpetev]

Clarification on the rejected status - after discussing today again, we're actually of the opinion this change might not be desirable. The root-provided service should only be included when actually needed and tree-shaken otherwise and, once the related leak was resolved, its overhead (empty map more/less) is quite minimal. On the other hand, providing it per component (sandboxing it) will create instance per component and there's a real concern with repeated/templated Selects/Combos for example and more dropdowns around the view UI we can end up with a hefty number of instances, which could be a worse tradeoff.

[pmoleri]

@damyanpetev somehow 1 service instance per component seems more expensive than 2-Map entries per-component? Can't be 100% sure, but my hunch is that the opposite is true.
IMO, root service means more complexity and more chances for mistakes (as already proven). And only worth it if there's a use case for it.

As a side note, I remember a conference from Ryan Dahl mentioning that he regretted not having Promises for node async APIs because his initial thought was that it meant an extra object per API call.

[pmoleri]

Also, it uses these ids which if I'm not mistaken their sole purpose is to be able to track the instances in the root service.