Fix grid edge counting, implicit vertex count and handle edge cases

[domischweisgut]

Dear KaGen Team,

When we wanted to benchmark the streaming generator for grid graphs, we encountered a problem if we want to generate all possible edges of a grid.
In particular, running

./build/examples/example_node_streaming "grid2d;x=4;y=4;m=24" 2 16

results in the following behavior:

Setting number of chunks to 4
Setting edge probability to 1.09091
Warning: configuration infeasible, too many edges
terminate called after throwing an instance of 'kagen::ConfigurationError'
  what():  Number of chunks must not exceed number of nodes
*** Process received signal ***
Signal: Aborted (6)
Signal code:  (-6)
[ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x45330)[0x74bdff245330]
[ 1] /lib/x86_64-linux-gnu/libc.so.6(pthread_kill+0x11c)[0x74bdff29eb2c]
[ 2] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x1e)[0x74bdff24527e]
[ 3] /lib/x86_64-linux-gnu/libc.so.6(abort+0xdf)[0x74bdff2288ff]
[ 4] /lib/x86_64-linux-gnu/libstdc++.so.6(+0xa5ff5)[0x74bdff6a5ff5]
[ 5] /lib/x86_64-linux-gnu/libstdc++.so.6(+0xbb0da)[0x74bdff6bb0da]
[ 6] /lib/x86_64-linux-gnu/libstdc++.so.6(_ZSt10unexpectedv+0x0)[0x74bdff6a5a55]
[ 7] /lib/x86_64-linux-gnu/libstdc++.so.6(+0xbb391)[0x74bdff6bb391]
[ 8] ./build/examples/example_node_streaming(+0x19731)[0x608e728a2731]
[ 9] ./build/examples/example_node_streaming(+0x3576d)[0x608e728be76d]
[10] ./build/examples/example_node_streaming(+0x2a9c6)[0x608e728b39c6]
[11] ./build/examples/example_node_streaming(+0x2319c)[0x608e728ac19c]
[12] /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x74bdff22a1ca]
[13] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x74bdff22a28b]
[14] ./build/examples/example_node_streaming(+0x23d75)[0x608e728acd75]
*** End of error message ***
Aborted (core dumped)

This reveals two problems:

1. The crash occurs because the number of nodes is not explicitly given, even though it is fully determined by the grid dimensions.
2. The edge probability is set to a value larger than 1, even though it should be exactly one (because in a 4x4 grid there are 24 (undirected) edges).

This PR addresses the above issues and some related edge cases:

1. If the grid dimensions are provided but n is not, we set the number of vertices to the value implied by the grid dimensions.
2. Grids such as 1x1 (1x1x1) are now rejected when p=0, since in these cases the maximum number of edges is necessarily zero and this is not feasible in this case (because m=0 was also not allowed before).
3. The previous logic for computing the maximum number of edges contained errors:

• In the 2D case, a 4x4 grid was counted as having only 22 edges instead of 24.
• This appears to stem from how degree-3 vertices were counted. Corner vertices were effectively subtracted only once, although they must be excluded twice.
• In the 3D case, degree-3 vertices exist as well (corner vertices), but were not accounted for in the computation of the maximum number of edges.

4. If periodic = 1, we have to look at the special case if one dimension is less or equal 2, since wrap-around edges might lead to parallel edges.
5. Generating more edges than a full grid allows is not possible. Hence, we now throw a ConfigurationError when m exceeds the maximum number of edges. If a different behavior is preferred here, please let me know.

I hope these changes resolve the mentioned problems. Please feel free to suggest adjustments or alternative behavior if desired.

[DanielSeemaier]

Thanks!