Fix: avoid writer issues with ranges returning __int128 from Ranges::size

[dglaeser]

In one application (using CGAL with the exact kernel) we ran into the case that for a given range, Ranges::size returned an __int128 with gcc. In particular, Ranges::size(grid_points) returned an __int128 when determining the number of points in the grid. This led to a compiler error because parsing to string for this data type didn't work, which is required to write the number of points into a vtk file.

This PR changes the result type of Ranges::size to std:.size_t. That is, in the mentioned case there is some precision loss. I'm not entirely sure why an __int128 was returned in this case. The standard does not specify the return type of std::ranges::size, but I believe most .size() functions of the standard library return std::size_t. I guess it's fine to simply cast to an std::size_t in this case. On typical architectures, it would only break for an insane amount of points/cells in the grid, I suppose.

[github-actions]

The following performance differences (this branch vs target branch) have been measured:
Relative deviation of average for 'app_raw': -0.31%
Relative deviation of average for 'inline_b64': 0.27%
Relative deviation of average for 'ascii': -0.38%
Relative deviation of average for 'app_b64': 0.22%

[github-actions]

The following performance differences (this branch vs target branch) have been measured:
Relative deviation of average for 'ascii': -0.09%
Relative deviation of average for 'app_raw': 3.92%
Relative deviation of average for 'app_b64': 1.67%
Relative deviation of average for 'inline_b64': 0.83%

[dglaeser]

ping @timokoch if you have 5 minutes some day. Should not take longer.

[timokoch]

Since it's a narrowing conversion it could at some point lead to a nasty bug I guess (once someone actually uses an extremely large range). But adding full support for __int128 probably takes quite some effort. Stating it somewhere in the docs, I think would be good though. So a section known limitations (or under the Caveats section in the readme) with the entry __int128 is not fully supported as a range size? (Or more general, integer types wider than std::size_t are not supported for integers larger than the largest std::size_t representable integer).

[dglaeser]

yeah I also thought it could be sketchy, that is why I requested a review. I doubt that it will really occur in practice, but if it does it'd be hard to track down. I will have a look at the use case again to see why this actually returns __int128. I understand CGAL operates on increased precision types when using the exact kernel, but I don't see why this should propagate to the range size... It would be nicer to circumvent it on the user side, or, have a way to control it (at compile-time) s.t. the compiler error has to be circumvented by user action.

This was a pragmatic "fix" that would probably work in 99% of the cases. The amount of cells/vertices you need for the narrowing to kick in is huge...