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 .
>This is also a sensible argument. Following that reasoning, however, gives us a std::string with both a push_back and an append that do the same thing. :-/ Regardless, I don't think we're going to have the last word on the subject. This is really for the committee to decide.

I agree but want to remark that a non-member non-friend `push_back` will do the right thing for string (without adding more bloat to its interface). It will facilitate writing generic code for a `vector<char>` and for a `string<char,..>` so I see it as a net win.

>  Although I wonder why you think that these should be defined for Iterable instead of a new Container concept.

`Extensible` is just a refinement of `Iterable`. That is, not every `Iterable` will model `Extensible`. I want, however, that at least those mutable `Iterable`s that own their elements do. This would exclude _almost_ every pair of iterators [0]. 

>I'm not sure what push_back means for, say, an pair of iterators. Is it like view::join? That has very different semantics, performance characteristics, and requirements. I don't think we want that.

I think this point is clear now. It means nothing, since most pair of iterators won't model `Extensible`. One can still "extend" them with `join` but one can do that with almost all ranges. Do we need a concept for that? We haven't yet but it is an interesting question. If we do it should be a different concept because as you say the semantics, requirements, and performance would be very different. Does `view::join` degrade the traversal category of a range? I mean if I join two `RandomAccessRange`s do I get a `RandomAccessRange` or a `BidirectionalRange`? 

[0] I want to leave the exceptions out first and see where we go but I'm thinking here of a pair of one `iterator` and a `back_inserter_iterator` where the `back_inserter_iterator` shares ownership of the elements of the container since it has a reference to it. Do such a pair of iterators model `Extensible`? It might, but I have to think more about this. Need a working `Extensible` concept prototype first.