Add more convenient container-construction overload for std.container.make

**(Depends on ~~#2359~~ for the example/test to work)**

This unifies construction of containers in a generic fashion.

Current approach:
```d
auto arr = Array!int(1, 2, 3);
auto list = SList!int(1, 2, 3);
auto rbtmax = redBlackTree!"a > b"(1, 2, 3);
alias makeIntegerList = make!(SList!int);
```

Proposed approach:
```d
auto arr = make!Array(1, 2, 3);
auto list = make!SList(1, 2, 3);
auto rbtmax = make!(RedBlackTree, "a > b")(1, 2, 3);
alias makeList = make!SList;
```

Currently, a container may choose to do one of two things: 1) rely entirely on its constructors for construction, or 2) define a convenience function for constructing an instance of that particular container. 

The problem with 1) is that the user needs to explicitly supply redundant information - the element type - which can be particularly tedious if the element type is generic, such as when constructing from a range in a range algorithm.

The first problem with 2) is the maintenance burden of needing to define and test a bunch of helpers. The second problem is the cognitive overhead that results from the user having to remember inconsistently named convenience functions (`redBlackTree` vs `heapify`), and their varying interfaces (if range-construction was added to `redBlackTree`, it would have 8 overloads).

Amending `make` in this fashion solves these problems. This change is 100% backwards-compatible with `make`'s current interface.

`BinaryHeap` currently does not fit this model as it is a kind of higher-order container. It could be made to fit by adding another template overload, but it requires some dubious template constraints, so I'm pushing that back to a future PR if this PR ends up being accepted.

Also moved `make`'s old example to a documented unit test.

Both of these templated function should have their constraints testing whether calling `.make` with the given arguments will even work. Otherwise, failure will result in the compilation error showing up inside of these functions instead of where they're called.