improve the build system to remove automatic vcs

[tonyfast]

sub issue from #162

• build system
  • the dynamic vcs junk just makes it hard to work vs. single source of truth
  • lark complicates things slightly, i guess
    • could start checking in the output to keep git+httpsinstallability

@bollwyvl can you describe the ideal situation we'd have that would remove these instabilities and more reliable builds?

[bollwyvl]

Basic idea:

# pyproject.toml
[build-system]
build-backend = "flit_core.buildapi"
requires = ["flit-core >=3.9.0,<4.0.0"]  # don't rely on lark

[project]
version = "..." # manually manage this single source of truth, or add light automation in `pixi`

# Remove all the `hatch` stuff.

# __init__.py
__version__ = __import__("importlib.metadata").metadata.version("importnb")

• use a pixi task to manage the .g --> .py
• check in the generated .py

The good:

• predictable filenames, very useful for file-based tasks
• remove full-fat hatch, used for publishing: big, includes setuptools

The bad:

• would need another tool to do the upload
  • potentially uv, which we're now using, but its uv publish might require buying into a whole second lockfile, without providing as much overall lifecycle value as pixi...
  • failing that, twine, which is itself not particularly lightweight
• .g hacking would be less convenient