[FEATURE] Add NAM_NO_FILESYSTEM option for bare-metal targets

[elcamino]

Problem

The core cannot be linked into bare-metal firmware (Arm Cortex-M, newlib), because NAM/dsp.h unconditionally includes <filesystem> and the loaders in get_dsp.cpp/dsp.cpp reference std::filesystem/std::ifstream. libstdc++'s filesystem implementation calls POSIX syscalls that newlib does not provide, so the link fails even if the application never loads a model from a path. Minimal reproduction (Arm GNU Toolchain 15.2, -mcpu=cortex-m7, newlib/nosys) with a single call to std::filesystem::exists():

ld: libstdc++.a(fs_ops.o): undefined reference to `truncate'

The affected targets are exactly where NAM increasingly runs: guitar pedals on MCUs (Daisy, Teensy). Embedded wrappers currently pin old core versions or carry local patches because of this; models on those targets load from embedded memory via the JSON/dspData entry points, never from a filesystem.

Change

An opt-in NAM_NO_FILESYSTEM define guards the <filesystem>/<fstream> includes and the path-based loader entry points (the two get_dsp(std::filesystem::path, ...) overloads and get_dsp_legacy). The JSON/dspData entry points are untouched. Without the define, the preprocessor output is identical to main, so existing builds cannot be affected.

Validation

• Default and -DCMAKE_CXX_FLAGS=-DNAM_USE_INLINE_GEMM builds: run_tests green (clang, Debug, same matrix as CI)
• All 13 NAM translation units compile with -DNAM_NO_FILESYSTEM; nm shows no filesystem/fstream symbols in any object
• In production use in a Teensy 4.1 (i.MX RT1062) firmware

Happy to add a CI configuration for the define if you want coverage.