Add backend extension-point hooks for out-of-tree FDTD backends

[Luochenghuang]

Summary

Adds a small process-global function-pointer table (POD layout, no virtual dispatch) that lets an external library, such as a CUDA, ROCm, or vectorized-CPU backend or an instrumentation shim, plug into meep's hot paths at load time without forking the codebase.

All hooks default to null. Null means "fall through to the in-tree CPU implementation." A stock build with no backend loaded behaves bit-identically to one without these hooks. This is asserted by a new test (tests/backend_hooks.cpp) that runs under make check.

What this PR adds

• src/meep/backend_hooks.hpp: a flat function-pointer struct (meep::backend_hooks) plus two inline helpers (sync_host_if_needed, read_field_at). Hooks: init, cleanup, step, sync_to_host, sync_from_host, read_point, needs_host_sync.
• src/backend_hooks.cpp: the process-global table, zero-initialized.
• fields::backend_state and fields_chunk::backend_state: opaque void * slots for backend-owned per-sim and per-chunk state. Upstream meep never inspects them.
• fields::backend_suspended: when true, the step hook is bypassed and the in-tree CPU step path runs instead. Used by solve_cw, which iterates against host arrays directly.
• Hook call sites at the points where backends need to interpose: step dispatch (step.cpp), sim lifecycle (fields.cpp), generic readout dispatcher (loop_in_chunks.cpp), get_field (monitor.cpp), dft_norm (dft.cpp), dump/load (fields_dump.cpp), solve_cw (cw_fields.cpp), and the LDOS hot path (dft_ldos.cpp).
• tests/backend_hooks.cpp: a counting "transparent" backend that implements every hook but defers all work to the CPU. Asserts (a) bit-identical numerical results between baseline and hooked runs, and (b) hooks fire at the expected sites with the expected counts. Runs in make check.
• doc/docs/Backend_Hooks.md: contract reference covering hook signatures, lifecycle ordering, opaque-state semantics, suspension, MPI contracts (collective step() return, etc.), and a tiny skeleton-backend example.

Total invasive change to existing source files: ~80 lines, all 1 to 7 line insertions. The bulk of the PR is the new header, the test, and the doc.

What this PR does not change

• Numerical results for any existing test or simulation. Every hook call is gated on a null-pointer check and runs no code when no backend is installed. The new test asserts this.
• The public Python or C++ API.
• The build system's defaults.
• Performance for vanilla meep. Each call site adds at most a single null-pointer test, which the branch predictor handles perfectly. The hot paths inside dft_ldos.cpp and monitor.cpp::get_field use the inline read_field_at helper that compiles down to a direct array load when no backend is installed (with -O2+ the conditional resolves at compile time after inlining and loop-unswitching).

Why

Today, anyone who wants to add a non-CPU backend to meep has to fork the repository and patch the same ~30 lines in step.cpp, cw_fields.cpp, the readout sites, and the fields class declaration. That fork then needs to be rebased against upstream forever. This PR turns that recurring patch into a stable extension point so backends can ship as out-of-tree libraries pinned to specific meep versions.

The motivating use case is a multi-GPU CUDA/NCCL backend that today lives as a fork; with these hooks, it can move to a sibling repo with no patches against upstream meep.

Hook surface

namespace meep {
struct backend_hooks {
  void    (*init)           (fields *f);          // per-sim setup
  void    (*cleanup)        (fields *f);          // per-sim teardown
  bool    (*step)           (fields *f);          // one FDTD timestep; return true to skip CPU path
  void    (*sync_to_host)   (fields *f);          // device -> host arrays
  void    (*sync_from_host) (fields *f);          // host arrays -> device
  realnum (*read_point)     (const fields *f, const fields_chunk *fc,
                             component c, int cmp, ptrdiff_t idx);
  bool    (*needs_host_sync)(const fields *f);    // gate for sync_to_host
};
extern backend_hooks meep_backend;
}

Defaults all null. Backends populate at load time (typically via __attribute__((constructor))).

MPI

The hook table is process-global; each MPI rank has its own. Backends are responsible for any cross-rank coordination (NCCL, MPI, sum_to_all, etc.). Meep never synchronizes hook invocations across ranks.

The doc page spells out the implicit contracts in detail. The most important one: step()'s return value must be collective. If one rank returns true (skip CPU path) and another returns false, the latter will execute step_boundaries, which calls MPI_Sendrecv, while the former will not, and the run will deadlock. A backend that handles some configurations but not others must agree across ranks before returning, or simply always return true once installed.

ABI

No formal ABI versioning. Backends are expected to be built against a specific meep version, like Postgres extensions or out-of-tree kernel modules. Adding a new function pointer at the end of the struct is forward-compatible because the global is zero-initialized; reordering or removing fields breaks ABI for already-built backends.

Open question

Naming. meep_backend_* (current) vs meep::backend::* vs something else. Happy to rename.

[stevengj]

This PR turns that recurring patch into a stable extension point so backends can ship as out-of-tree libraries pinned to specific meep versions.

I'm not sure the goal of Meep development is to make it easier to maintain private forks?

Note that you can't "ship" proprietary out-of-tree backends outside of your company due to the GPL, though of course you can use modified private forks in-house without distributing.