Feature/counting algorithms

This feature contains the following modifications:
* Re-factor counting algorithms: `num_points`, `num_segments`, `num_geometries` and `num_interior_rings`: this refactoring involves moving common code to a separate file `algorithms\detail\counting.hpp` and a new namespace that I called `bg::detail::counting`. As part of the re-factoring, the `num_points` code in the `multi/algorithms` directory was also moved in the `algorithms` directory.
* Add variant support for `num_interior_rings` and `num_geometries`.
* Add unit tests for `num_interior_rings` and `num_geometries`.
* Implement `num_points` and `num_segments` for boxes of any dimension: to do this I implemented the Boost.MPL-based metafunction `ipower` in the `bg::util` namespace that computes the power of an integral constant at compile time (there is also a unit test for this metafunction). As part of this change, the unit tests for `num_points` and `num_segments` now test for boxes of dimensions 3, 4 and 5.
I don't see it like that. A triangle has always 3 segments no? The problem is not in the number of segments. That should always return 3, for a triangle (open or closed).
The problem is in the number of points. Ideally that should return 3 too. Because a triangle obviously has 3 points. But for closed polygons (which is the OGC standard, and our default) it stores 4, and num_points according to OGC returns 4. Therefore we have to enable that option too, and it is enabled by default. Because this was the first implementation we added the add_for_open flag (which is of course optional) for open polygons. Alternatively we could have added a "remove_one_for_closed" flag, maybe that would have been better...

But for a new non OGC function let's not make the same discrepancy. Rings are always closed (regardless if the model is open or close) so the number of segments should be the same for spatially the same ring.