non-static variant::visit

Nobody has claimed this yet.

I'm creating this separate issue to keep the discussion in #113 clean.

> @artemp Because variant::visit doesn't modify internal state and making it static gives compiler some hints on how to generate binary code. Why are you thinking it shouldn't be static ?

What hints? Visiting a non-const variant _can_ modify internal state (e.g. comparison operators can give different results after such visit; edit: that's modifying external state, actually).

`visit` is a static member function template only by syntax. Its first argument is always a reference to the class it's defined in. That's identical to non-static member functions under the hood.

Why this:

``` c++
template
auto VARIANT_INLINE apply_visitor(F&& f, V& v) -> decltype(V::visit(v, std::forward(f)))
{
return V::visit(v, std::forward(f));
}
```

instead of this:

``` c++
template
auto VARIANT_INLINE apply_visitor(F&& f, V& v) -> decltype(v.visit(std::forward(f)))
{
return v.visit(std::forward(f));
}
```

// ignoring for now that `V` should be forwarded as well

Start by reading issue #113 and the discussion here, then inspect the existing visit and apply_visitor entry points. Compare the static and non-static call forms, including behavior for non-const variants. Done means the design question is resolved and the chosen API behavior is documented and covered by appropriate tests.

Written by the indexing model from the issue text.