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.

You see the exact same expression either way. The difference is whether you have to see that expression in the documentation or not, and since it's part of the implementation, the user should not be concerned with it. Thus this overload of `make` is incomplete because Phobos lacks trait checkers for containers, which is a task much bigger than this PR.