insert/push_back/push_front range extension

Add range-based non-member non-friend insert extension, push_back/push_front utilities that build upon it, and RANGE_RETURNS utility macro.

Closes #4 .
I think providing a non-member insert as a customization point is a great idea. I'll work it out and update the PR. 

>Other things to think about: is there a Container concept that is then refined by ExtensibleContainer, like in MPL? Perhaps ExtensibleContainer is a Container that is Insertable, BackExtensible, and FrontExtensible. 

Since `Iterable`s can own their elements I use that term below instead of `Container` (whose requirements are not so clear to me).

First, `Insertable` `Iterable`s  are also `FrontExtensible` and `BackExtensible` since with `insert` one gets generic `push_back` and `push_front`. The opposite is, however, not true: with `push_back` and `push_front` one doesn't get a generic O(N) `insert`. So the concepts I think make sense here are: 
- `FrontExtensible` `Iterable`:  `push_front(FrontExtensible out, value)`, `push_front(FrontExtensible out, InputIterator input_begin, Sentinel input_end)`, and `push_front(FrontExtensible out, InputIterable input)` are valid-expressions.
- `BackExtensible` `Iterable`:  `push_back(BackExtensible out, value)`,  `push_back(BackExtensible out, InputIterator input_begin, Sentinel input_end)`, and push_back(BackExtensible out, InputIterable input)` are valid-expressions.
- `Insertable` `Iterable`: `insert(Insertable out, InputIterator position, value)`, `insert(Insertable out InputIterator1 position, InputIterator2 input_begin, Sentinel input_end)`, and `insert(Insertable out, InputIterator position, InputIterable input)` are valid-expressions.

where `Insertable` `Iterable`s model `FrontExtensible` and `BackExtensible`.

Is there anything that refines these concepts but is itself not an `Iterable`? I don't think so. 

> What interesting container algorithms would we want to define ?

I want `push_back`/`push_front`/`insert`/`erase_if`. Then there is the controversial `grow(n_front, n_back)`/`grow_front(n)`/`grow_back(n)` (basically the opposite of `slice`) which might be safer to use with `Extensible` `Iterable`s than with `Range`s. I don't know what it brings to the table since I never had it/used it. Might be worth it to just try it out.  

>what container types do we want to support, (sequence? segmented? node-based? associative? unordered?)

I think this question is not the right one since we want to support all `Iterables`. I think that a better question here is "What semantic aspects of Iterables are impossible to capture with the concepts that we already have?". 

For instance, the concepts that `Iterables` are:
-  extensible: `Insertable`(`Extensible`) / `FrontExtensible` / `BackExtensible`... `NodeExtensible` (refine a quadtree node).
- reducible:  `Reducible` (`erase_if`)
- already sorted or not sortable: `Sorted` (ordered containers, the result of a call to `sort`) `Unordered` (unordered containers)
- to be traversed like a `Sequence`, `SegmentedSequence`, `Graph`, `SegmentedGraph` (e.g. binary tree, quadtree, octree, ...), maybe even `Directed`/`Undirected` graphs, ...
- allocated in memory: linear elements (vector, array), segmented linear elements (deque), linear node based, pointer chaising (list)...

All this concepts add some metadata (semantic information) that the compiler cannot infer but could potentially (with a lot of work) be used to select a different better algorithm at compile time, give a better error message on misuse, ...

I think `Extensible` is a good start, `Reducible` with `erase_if` will follow. `Sorted` could both prevent errors like calling `unique` with an unsorted sequence, and allows optimizations like binary search when `find` is called. It is, however, a lot of work to get it right. The other possible paths for range-based concepts above are an endless wish list but whatever direction the library takes, if someone wants to build a SIMD library using ranges they should be able to get their ranges to interoperate with the standard algorithms and concepts.