CLI UX improvements and build system revamp

[alecthomas]

• Fast-path dependency extraction from import lines #963
• Most (all?) build commands are provided a set of modules to build with. This can be combined with the live modules on a cluster to provide the complete set of modules available when performing dependency resolution. #985
• Local development. Should start server, build, deploy, hot reload. #979
• Should be able to build and deploy everything and then run tests against the running cluster #962
• ftl deploy will recursively build and deploy all modules in the provided paths, by default it will block until either a timeout error occurs or all modules are deployed and live. feat: use buildengine for deploy cmd #1002
• Move build logic into top-level buildsystem package. #961
• Filesystem monitoring for module changes #969
• Move codegen from Maven into the ftl tooling. #970
• Mechanism to find all local modules. #967
• Function that takes a module list and all local modules, and converts it into a dependency graph. #966
• (1) Add a system for building and optionally deploying a single module - extract schema, (optional?) build, (optional) deploy #973
• (2) Another system for repeatedly building in parallel until everything reconciles.
• (3) Live reloading system which will restart builds for individual modules. #1027
• One of these systems needs to understand schema dependencies and which modules to rebuild when modules change.
• We will need a bounded work queue to avoid killing the users computer.
• We'll want a flag to control concurrency.
• Ideally each build system can feedback how concurrent it is. eg. if each Go build uses 10 cores, we don't want to build 10 Go modules at once.
• Alternatively, have a way to limit the concurrency of each build.

Use cases

Echo/time example

1. Build system loads dependency graph (fast-path extraction):

    echo -> time
    time
   

2. Builds time, extracting schema to time/_ftl/schema.pb

3. Build tool loads the schema.

4. Start building echo

5. Code-gens Kotlin stubs for time based on dependency graph

6. Build Kotlin

Unit tests/CI

ftl build          # Just works
go test ./...     # Just works

Integration tests/CI

ftl serve --background --recreate
ftl deploy  # Waits for modules to deploy
go test -tags integration ./...
ftl serve --stop

Interactive development

ftl dev
# Profit

Non-interactive development

ftl build
# Profit

[KendallWeihe]

Could we introduce a command to stop/restart the background cluster? Rather than having to ps aux | grep ftl and kill -9 it, we could do something like ftld stop ("d" for daemon? idk just spitballing to illustrate the idea)

---

Edit: this already exists, ftl serve --stop