Include FFLAGS on the multilayer link line so OpenMP builds link correctly

[mandli]

There was an inconsistency in the way link flags $(LFLAGS) were dealt with in the multilayer Makefile. This was mostly due to the requirement that it needs to build against something that looks like LAPACK.

While we were reviewing the Makefile behavior in other places we did notice that examples/bouss/radial_flat/Makefile hardcodes -fopenmp instead of $(FFLAGS). This is fragile as and drops other flags that may be included elsewhere. It may argue for making ALL_LFLAGS always include FFLAGS.

[mandli]

PR Detailed Description -- Summarized by Claude

The mechanism

Makefile.common:84 supplies the link flags with

LFLAGS ?= $(FFLAGS)

?= assigns only when the variable is still unset. An example Makefile
includes Makefile.multilayer before Makefile.common
(examples/multi-layer/plane_wave/Makefile: line 31 vs line 58), and
Makefile.multilayer opens with

LFLAGS += -framework Accelerate     # or MKL / -llapack on Linux

By the time Makefile.common is read, LFLAGS is already set, so ?= never
fires and the default is silently cancelled. Nothing warns; the LAPACK flag is
present, so the line looks fine.

The result is that everything in FFLAGS is dropped from the link. With
-fopenmp the sources compile with OpenMP but the link has no OpenMP runtime:

Undefined symbols for architecture arm64:
  "_GOMP_critical_name_end", referenced from:
      _igetsp_ in igetsp.o

make new does not help, because this is a link-flag problem, not a stale
object problem.

Makefile.multilayer was the only LFLAGS += site in geoclaw that omitted
$(FFLAGS). The others already carry it, which is why only the multilayer
examples broke:

Site
examples/storm-surge/isaac/Makefile:27	LFLAGS += $(FFLAGS) $(NETCDF_LFLAGS)
examples/tsunami/bowl-slosh-netcdf/Makefile:29	LFLAGS += $(NETCDF_LFLAGS) $(FFLAGS)
tests/regression/met_forcing/Makefile:23	LFLAGS += $(FFLAGS) $(NETCDF_LFLAGS)

The change

One line, added once at the top rather than repeated in each of the three
platform branches:

LFLAGS += $(FFLAGS)

LFLAGS stays recursively expanded, so $(FFLAGS) is resolved at link time
rather than at include time. That matters for the ifort branch, which appends
-I$(MKLROOT)/include to FFLAGS after this point — the deferred expansion
picks it up. It also means a user's own later FFLAGS additions are honoured.

The rest of the diff is comment explaining the trap, since the failure mode
gives no hint about where to look.

Verification

Reproduced the failure before fixing, on examples/multi-layer/plane_wave
with FFLAGS=-fopenmp:

	LFLAGS as make expands it
before	-framework Accelerate
after	$(FFLAGS) -framework Accelerate

Resulting link line now ends -fopenmp -framework Accelerate -o xgeoclaw.

• plane_wave, FFLAGS=-fopenmp make new — links; make .output runs to
  completion under OMP_NUM_THREADS=2, so this is not just a successful link.
• bowl-radial, FFLAGS=-fopenmp make new — links.
• plane_wave with FFLAGS unset — still builds, confirming nothing changed
  for the non-OpenMP path (LFLAGS then expands to just the LAPACK flag plus
  an empty FFLAGS, which is what ?= would have produced anyway).

On the radial_flat / ALL_LFLAGS point in the description

Two separable things, both deliberately left out of this PR:

• examples/bouss/radial_flat/Makefile:76 — LFLAGS += $(PETSC_LFLAGS) -fopenmp
  hardcodes the flag rather than $(FFLAGS). It works today only because
  -fopenmp happens to be the flag that matters; any other user FFLAGS entry
  needed at link time is still dropped.
• Making ALL_LFLAGS always include FFLAGS in Makefile.common would remove
  the trap for every downstream Makefile at once, so no include order could
  cancel it. It is the better fix, but it is a clawutil change that would
  double-add FFLAGS for the three Makefiles above that already include it
  explicitly. Harmless for linking, but it is a semantics change across every
  Clawpack package and wants its own PR and discussion rather than riding along
  with a geoclaw bug fix.