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.

Okay. It looks like there's enough information on the error now. It used to be that you'd just get the line inside the function rather than where the function was called, making it so that you really would need to put it in the constraint, even if it _is_ an annoying piece of code duplication. I was thinking that that was still the case, but fortunately it isn't. So while ideally, the constraint would have the check in it, it's not as critical as it used to be. I'd probably still put the check there if I were writing it, but I can understand not wanting to put it there, and I think that we can get away with it in this case.