Scope: IntegratorXX builds atomic grids, GauXC is the molecular driver

[susilehtola]

Opening this to record a scope decision that has so far been implicit, and
to note what follows from it.

The boundary

• IntegratorXX builds atomic grids. High-level construction: radial
  rules, angular rules, their spherical product, pruning. Setup-time work on
  compact data. No GPU support is needed or wanted here.
• GauXC is the molecular driver. The low-level constructions -- basis
  set screening, collocation, XC evaluation -- and the performance work that
  goes with them.

Current state

There is no molecular-grid machinery in this repository at all. A search for
voronoi, fuzzy, partition_weight, becke_weight, multicenter,
nuclei and atom across include/, src/ and test/ returns nothing.
The only Becke here is the radial transformation from section 2 of J.
Chem. Phys. 88, 2547 (1988); the fuzzy-cell partitioning from section 3 of
the same paper is absent.

The README claimed "atomic and molecular grids"; the accompanying
documentation PR corrects that and points at GauXC.

What this leaves open

SphericalMicroBatcher is the one class here that exists to serve the
downstream molecular problem: it partitions a grid into spatially compact
boxes and computes a bounding box per batch, which is what both the
partition-weight screening and shell screening want. Two things follow:

1. It is on the critical path but barely tested. It has one test file.
   Recent fixes to it (missing <algorithm>, an uncompilable
   const_iterator, iterator typedefs that std::iterator_traits could not
   see) were all found by inspection rather than by tests.

2. It discards the bounding boxes. iterator::operator* recomputes them
   on every dereference via get_box_bounds_points and returns them by
   value, rather than retaining what generate_batches already computed. If
   a downstream screening loop wants them per batch, that is wasted work.

If the partition weights are to stay downstream, then the question is
whether the batcher itself is better owned by GauXC, and whether
IntegratorXX should simply expose the grid and let the consumer batch it.

Note that the partition weight needs only grid points and nuclear
coordinates -- no basis, no density -- so it is one of the few pieces that
could live on either side of the line. Recording the decision here so it is
not re-litigated later.

Not proposed here

GPU support for grid construction. Construction is cheap and the data is
compact; the expensive parallel work is in the molecular driver, where it
belongs.