[Heap] Remove Heap's ascending and descending views

[lorentey]

These two do very non-trivial processing, so they don't at all work like views in the Standard Library.

They also don't carry their weight -- they are simply lightweight wrappers around popMin and popMax, respectively.

Let's get rid of them before we etch them in stone as public API.

Checklist

• I've read the Contribution Guidelines
• My contributions are licensed under the Swift license.
• I've followed the coding style of the rest of the project.
• I've added tests covering all new code paths my change adds to the project (if appropriate).
• I've added benchmarks covering new functionality (if appropriate).
• I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
• I've updated the documentation if necessary.

[lorentey]

Cc @AquaGeek

[lorentey]

@swift-ci test

[CTMacUser]

Isn't it better that we centralize the non-trivial work than everybody writing their own wrapper implementations? And it's better than putting Sequence conformance directly onto Heap (which can't be done symmetrically for ascending and descending views).

What are some examples of trivially processing views in the Standard library?

[lorentey]

Isn't it better that we centralize the non-trivial work than everybody writing their own wrapper implementations?

In this case, I don't think this characterization is fair. I actually don't see any practical use cases for heap.ascending/descending -- the iterators of these sequences make a full copy of the underlying storage the first time next() is called, which is a performance gotcha that is (as far as I can remember) unique to these two. This gotcha means that these constructs don't work like views at all, and using them in production would likely be a bad idea.

Heaps are emphatically not general-purpose collection types. Heap's API must be designed to serve their intended purpose, which revolves around the insert & popMin/popMax operations of the abstract priority queue data type. Direct element access is not part of this at all. (Not that ascending/descending provides that.)

And it's better than putting Sequence conformance directly onto Heap (which can't be done symmetrically for ascending and descending views).

I don't think Heap needs a Sequence conformance at all. Assuming we do want to allow iteration over heap items, exposing the underlying array (as done by unordered property) is the right way to go at this.

What are some examples of trivially processing views in the Standard library?

To be specific, by "trivial" I meant views whose iterator does not mutate (and hence, copy) the underlying storage. In this sense, every view provided by the stdlib is trivial. (String's various encoding views, Dictionary's keys and values views all work like this, as well as vaguely view-like things such as slices, lazy algorithms, etc.)

I we want to put a label on it, "regular" or "lightweight" would probably work better than "trivial".