feat: migrate build system from Makefile to CMake

[andeplane]

Summary

This PR migrates the build system from the old Makefile-based approach to a modern CMake-based build system, matching the approach used in atomify-main.

Changes

• Replaced cpp/build.py with CMake-based version that:

  • Uses emcmake cmake to configure LAMMPS with Emscripten
  • Leverages LAMMPS's native CMake build system
  • Supports configurable packages via PACKAGES env var (default: MOLECULE)
  • Supports SINGLE_FILE mode to embed WASM in JS (default: enabled)
  • Supports debug builds with --debug flag
  • Supports force recompilation with --recompile flag

• Removed cpp/Makefile - no longer needed since CMake handles compilation

• Updated GitHub workflows to set EMSDK_PATH environment variable required by the new build script

Benefits

• Better dependency management (CMake handles Voro++, COLVARS, etc. automatically)
• Cleaner build orchestration
• Consistent with modern LAMMPS build practices
• Easier to extend with additional packages

Testing

• ✅ Build completes successfully locally
• ✅ All 9 existing tests pass
• ✅ Output file cpp/lammps.js generated correctly (10MB with embedded WASM)

Usage

# Basic build (requires EMSDK_PATH env var)
EMSDK_PATH=/path/to/emsdk python3 cpp/build.py

# With additional packages
PACKAGES="MOLECULE KSPACE" python3 cpp/build.py

# Debug build with source maps
python3 cpp/build.py --debug

# Force full recompilation
python3 cpp/build.py --recompile

[andeplane]

I think we should consider maybe deploying multiple versions with different set of packages. Not sure exactly how we should do it though.

[alexjilkin]

Makes sense!

[alexjilkin]

Looks good! important improvements.

It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?

Otherwise, tested, works well on my machine and the threejs examples continues work.

[andeplane]

Looks good! important improvements.

It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?

Otherwise, tested, works well on my machine and the threejs examples continues work.

Right, yes. Maybe we don't want that and want to have sourced emscripten first and just use global ref to binaries?

[alexjilkin]

Looks good! important improvements.
It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?
Otherwise, tested, works well on my machine and the threejs examples continues work.

Right, yes. Maybe we don't want that and want to have sourced emscripten first and just use global ref to binaries?

Looks good! important improvements.
It means that now if I'm trying to use the build:wasm install script, then a EMSDK_PATH="<some_path>/emsdk" npm run build:wasm is necessary, right?
Otherwise, tested, works well on my machine and the threejs examples continues work.

Right, yes. Maybe we don't want that and want to have sourced emscripten first and just use global ref to binaries?

So you mean that the developer will first source it independently, and the project expects to have it as a global ref? I think it's a fine solution. But I also think that having this export param is OK for now.