feat: isolate hardcoded language support

[matt2e]

Part of #2452
In preparation for language plugins, this PR defines a protocol for each language support to conform to. Later we will define the external plugin gRPC service and then move each language to being an external plugin one by one.

Breakdown of components:

Build engine

• Watches for:
  • added and removed modules
  • updates to ftl.toml
• Asks a module plugin to build when:
  • explicitly asked (eg: ftl build)
  • dependencies are updated
  • ftl.toml is updated
• Listens to each module plugin's Updates topic to react to automatic builds

Module plugin

Currently these plugins arent actual plugins, but they will be soon!

• Can be used to scaffold a new module (ftl new ...)
• Gathers dependencies for a module
• Builds when asked by the build engine
• Watches for file changes within the module (language dependant. excludes ftl.toml)
  • When a change is detected, publishes automatic build events to it's Updates topic

Not included in this PR (coming in a later one):

• allow ftl new to have language specific arguments (currently go and jvm ones are hardcoded into cmd_new.go)
• currently no logic for collapsing multiple build requests into one or detecting if we have already built since a file change event was fired. This logic needs to change for external plugins anyway.

[matt2e]

Schema is going to be passed back from plugins over gRPC, so modules themselves shouldn't be configuring the location of the schema file.

[alecthomas]

Nice, thanks Matt.

[alecthomas]

Maybe create the logger once at the top?

[matt2e]

The logger needs to be scoped to the module, but the loop is for all modules. So it needs to be done per event