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?
I'm wondering why it was deprecated. It's possible that this approach may not work for all Ranges. I didn't test it yet but e.g. when a tempoarary range was generated by operator| it would be a const object but still handling mutable values. So maybe we should come up with some better solution/tool for Ranges.