Fix/closing iterator

This PR adds a support for mutable Geometries to `closing_iterator<>`.

The rationale for this change:
1. In the comments of `closing_iterator<>` it states:
_Use with "closing_iterator<Range> or "closing_iterator<Range const>to get non-const / const behaviour_
2. Without it `closeable_view<>` can't handle mutable Geometries so, e.g. can't be used in the implementation of `for_each_segment()` (see: https://github.com/boostorg/geometry/pull/147).

This PR replaces the value_type used by `closing_iterator<>` from `range_value<R>::type const` to the one defined by `add_const_if_c<is_const<R>::value, range_value<R>::type>::type`.

Though I'm not sure if this fix should be applied. Supporting mutable geometries in `closing_iterator<>` means supporting them in `closeable_view<>` and I'm not sure if this is intended since this view is used internally only with non-mutable Geometries (not taking into account the change made by https://github.com/boostorg/geometry/pull/147).

We could of course "fix" the iterator but use `closing_iterator<Geometry const>` for both `iterator` and `const_iterator` types in `closeable_view<>` but then this view couldn't be used in `for_each_segment()` and honestly the "fix" wouldn't have much sense since this iterator is only used by the view.

So the question is, should views handle only non-mutable Geometries or could this requirement be relaxed, at least for some of them?
It is necessary. I have had similar issues in point and segment iterator, where I had to explicitly qualify the range value with const. I am not using `add_const_if_c`, but some other metafunction I wrote. But I guess I should probably remove the custom metafunctions and use `add_const_if_c`.