Fix type mismatch when non-default float types are used in sparse_reduce

[kasparas-k]

Currently, sparse_reduce does not specify dtype when initializing new_out_features with zeros:

WarpConvNet/warpconvnet/nn/functional/sparse_pool.py

Lines 98 to 102 in d9082e8

	new_out_features = torch.zeros(
	batch_indexed_out_coords.shape[0],
	in_features.shape[1],
	device=voxels.device,
	)

This leads to an error when using any type other than torch.float32:

File "/opt/conda/lib/python3.11/site-packages/warpconvnet/nn/functional/sparse_pool.py", line 103, in sparse_reduce
    new_out_features[unique_out_maps] = out_features
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
RuntimeError: Index put requires the source and destination dtypes match, got Float for the destination and Double for the source.

This commit fixes the issue. I have also looked through all other uses of torch.zeros in the code. I did not find any other parts that do not specify a data type save for one line:

WarpConvNet/warpconvnet/nn/modules/mlp.py

Line 92 in d9082e8

self.bias = nn.Parameter(torch.zeros(num_matrices * out_features))

But since it's part of initializing a module, it should probably be fine, as the types of module weights are usualy cast all at once once the model was fully instantiated.

[kasparas-k]

I found that this code path gets triggered when the absolute values of the coordinates are very large (in my case the y coordinate was over 5e7) when one forgets to apply an offset. After offsetting the point cloud, I no longer trigger that code path where len(unique_out_maps) != batch_indexed_out_coords.shape[0]. I'm not sure what is the source of this behavior, since the batched indices are int32 and even when voxelizing such coordinates, it should not overflow.