Feature/dynamic bonding

[astatt]

This is the current state of the dynamic bonding code which I need some feedback and help on, @mphoward. The plan is to test hoomd 5.4.0 and cuda/12.6 first before moving it to hoomd 6.0, although it doesn't compile currently on the GPU. The CPU code works and is mostly tested.

The two big roadblocks are currently:

• import the correct headers for extern/neighbor. something is going wrong there that makes me unable to compile the GPU code. I marked the headers in the respective files with "@mphoward"
• while the CPU code compiles, there is a code duplication that is necessary due to the stricter access rules on GPUArray and GPUVector. I marked the function and the two spots it shows up in the code for you to review.

Still todo before this can be merged:

• resolve header issues with extern neighbor package
• make sure GPU code works otherwise
• port unit tests, make sure they pass
• resolve CPU code duplication (or decide to be OK with it)
• port code to hoomd 6 once it compiles/works
• remove all spurious print statements and comments, general code cleanup
• larger scale systems test

[astatt]

This is now implemented on the CPU and GPU, code still needs cleanup. It passes the non-MPI unit tests, which make sense, I think bigger modifications for MPI might be needed because of the global loop over all possible bonds when they are formed. We might just want to say that this module doesn't work for MPI.

@mphoward what do you think about supporting MPI? I haven't thought about how one would do it because we would need to think about how to handle the system wide for loop over all possible bonds to form them sequentially.

[mphoward]

Great! For azplugins features, I am perfectly fine with not supporting MPI if it is not needed for your research. In this case, please make clear in the documentation with a note or warning that MPI is not supported, then add error checking at the Python and C++ level for running on multiple ranks.

If you envision using this code on multiple CPUs, I am also happy to take a look to see if I can suggest how to support MPI.

[astatt]

@mphoward If you have some time, could you see how much work you think a MPI implementation would be? There are various arrays where communication would be needed (e.g. m_all_possible_bonds, m_num_all_possible_bonds,...) but then I assume that the actual generation of bonds (makeBonds()) should be done only on one rank and then be communicated back out. For now, I put an error into the cpp constructor, so the code will error out with MPI.

The code is not yet polished or cleaned up, but it is fully functional on the GPU and CPU. I expect that there are many improvements that can be made, feel free to point them out now or wait for an actual pull request review.