Expose `max_neighbors` argument for `batch_naive_neighbor_list`

[jvita]

The batch_naive_neighbor_list function in nvalchemi-toolkit-ops supports specifying the max_neighbors argument, which is useful when working with systems that happen to be denser than the default estimate by the estimate_max_neighbors function in nvalchemi-toolkit-ops.

There are plenty of other examples of useful arguments in the neighbor list functions from nvalchemi-toolkit-ops. Vesin doesn't look like it has as many additional options.

A possible solution might be to support argument pass-through in torchsim_nl by including a **kwargs that gets forwarded all the way down to _batch_naive_neighbor_list. While this would throw an error if a user provides an invalid argument, it would still be quite convenient. However, I'm not sure what other areas of torch-sim it might affect.

[CompRhys]

Would be glad to look at a PR for this. I only saw this edge case in very extreme skewed unit cells we had in the old test suite and so I am unsure how common a failure mode it is. If there's a clean pathway to expose then we should expose it. Ideally we would like to try keep as much typing as possible so potentially a discriminated union of dataclasses for each of the fallbacks might be the way to do it.