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.

I hope we will have appropriate constraints in the future, but until then, putting the entire function body in the constraint is just pointless. I have no idea why you say you would still do it. Sounds like dogma to me.

The container concept in general still needs fleshing out, though after having written some generic container algorithms, I'm optimistic about the current base we have.