Refactor CI workflows

[joaander]

Description

Move away from jinja templated workflows to reusable workflows

A future PR will migrate to base Ubuntu templates with micromamba provided build dependencies. With micromamba and conda lock files, bumping a single dependency (e.g. numpy) no longer requies long docker image builds. However, moving from jinja templates to reusable workflows is enough for one PR on its own.

Motivation and context

Make it easier to update workflows and allow dependabot to update GitHub actions versions.

How has this been tested?

CI checks.

Change log

Changed:

• Test with gcc14, clang17, and clang18. No longer test with clang10
  (#1798 <https://github.com/glotzerlab/hoomd-blue/pull/1798>__).

Checklist:

• I have reviewed the Contributor Guidelines.
• I agree with the terms of the HOOMD-blue Contributor Agreement.
• My name is on the list of contributors (sphinx-doc/credits.rst) in the pull request source branch.

[joaander]

clang18 adds warnings when variable length arrays are placed on the stack. HOOMD-blue code did so in a variety of places. I replaced these with std::vector in the MPI code. Benchmark before and after (mpirun -n 24 python3 -m hoomd_benchmarks.md_pair_lj --device CPU -v -N 64000 --warmup_steps 10000 --benchmark_steps 1000 --repeat 10):

• Before: 269 TPS
• After: 269 TPS
  The MPI std::vector allocations are once per timestep (or less often?), so they do not impose an overhead.

I used a large fixed size stack array in the convex polyhedron support function. This code is called in the innermost loop, so std::vector will severely impact performance here. I added an error check to prevent stack overflows. The max size is 4096 vertices which should be much larger than any reasonable use-case for convex polyhedron overlap checks.
Benchmark (python3 -m hoomd_benchmarks.hpmc_octahedron --device=CPU -v -N 1000 --repeat 10)

• Before: 866 sweeps/s
• After: 919 sweeps/s
  With the now force inlined methods, the fixes stack allocation occurs only once per timestep. Even when including the forceinline changes, the fixed size stack allocation is faster than the variable length arrays.