feat: add ProviderScopes

[manuel-plavsic]

Currently the other PR (#17) has some problems: circular dependencies and it is not tested with some provider reusage in different, coexisting subtrees (at the moment it clearly introduces bugs).

This PR does not present the above problems (and in generally it shouldn't introduce new ones, since ProviderScopes uses ProviderScope internally without changing the existing code).

ProviderScopes offers a similar API but allows multiple scopes at once. Here is how it looks like:

ProviderScopes(
  providers: [
    [numberProvider], # each list represents a scope
    [doubleNumberProvider],
  ],
  child: Builder(
    builder: (context) {
      final number = numberProvider.of(context);
      final doubleNumber = doubleNumberProvider.of(context);
      return Text('$number $doubleNumber');
    },
  ),
),

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

@@            Coverage Diff            @@
##              main       #18   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            9         9           
  Lines          215       215           
=========================================
  Hits           215       215           

[manuel-plavsic]

If possible, it would be great to add a lint package that detects e.g. ProviderScopes with only one scope and suggests to change it to ProviderScope. And if there are two nested ProviderScopes it suggests refactoring to a ProviderScopes.

[nank1ro]

this model has no sense, it's like using two nested ProviderScopes, which is more simple for the user.
never add a model (complexity) when not needed, we should keep things simple. Just one way of doing things is better

[manuel-plavsic]

I thought the main problem in the other PR was that there was a lot of nesting involved, and this solution while being cumbersome is at least safer and allows to get rid of repetitive nesting.

However, I agree, we should only keep the current implementation in main, so I am closing.