Allow hiding of conflicting extensions

[Pascal Welsch]

Currently, it is not possible to hide individual extension function which conflict with extensions of other packages. It's only possible to hide a whole "extension groups" such as IterableExtension, but not IterableExtension.sortBy individually.

Please wrap every extension function in an individually named extension so it can be included/excluded with hide/show.

Example:

/// Currently
extension IterableExtension<T> on Iterable<T> {
 
  List<T> sample(int count, [Random? random]) {
    // ...
  }

  Iterable<T> whereNot(bool Function(T element) test) {
    // ...
  }

  List<T> sortedBy<K extends Comparable<K>>(K Function(T element) keyOf) {
    // ...
  }
}

/// Proposal
extension SampleIterableExtension<T> on Iterable<T> {
  List<T> sample(int count, [Random? random]) {
    // ...
  }
}

extension WhereNotIterableExtension<T> on Iterable<T> {
  Iterable<T> whereNot(bool Function(T element) test) {
    // ...
  }
}

extension SortedByIterableExtension<T> on Iterable<T> {
  List<T> sortedBy<K extends Comparable<K>>(K Function(T element) keyOf) {
    // ...
  }
}

[Pascal Welsch]

The consequence is that is isn't possible to use some extensions from dartx and some extensions from collection in the same dart file. Both libraries expose only a single extension on Iterable<T>.

[Lasse R.H. Nielsen]

You can use both, you just have to use a prefix for one of them. I can see why collection.IterableExtension(o).sortBy is less convenient than o.sortBy, but mixing and matching extension with the same name on the same type is not something the extensions language feature was designed for.
It's not surprising that iterables/collections is where a conflict like this occurs, though.

I recommend importing both extensions without prefixes, and also the ones you need to resolve a conflict for with a prefix, and use prefix.Extension(o).sortBy() to resolve the conflict. That's the recommended approach which works without needing to change the original libraries.

[Jacob MacDonald]

This would also be a breaking change in this package to move them to new extensions... I don't think this change would justify the amount of churn caused by doing that - especially when flutter pinning is taken into account. The current situation is we actually don't allow any breaking changes in any package pinned by flutter because it creates a major version lock problem (this situation is unfortunate, but it is what it is).