fix: GetModuleContext: use config from context instead of from envar

[safeer]

Fixes #1352

With this change, the behavior is:

• ftl dev examples/go
  • uses ftl-project.toml in the gitroot if it exists
• FTL_CONFIG=ftl-project-inline-a.toml ftl dev examples/go
  • uses ftl-project-inline-a.toml
• ftl dev examples/go --config=ftl-project-inline-b.toml
  • uses ftl-project-inline-b.toml
• FTL_CONFIG=ftl-project-inline-a.toml ftl dev examples/go --recreate --config=ftl-project-inline-b.toml
  • uses ftl-project-inline-b.toml

[deniseli]

For your fourth case:

• FTL_CONFIG=ftl-project-inline-a.toml ftl dev examples/go --recreate --config=ftl-project-inline-b.toml
  • uses ftl-project-inline-b.toml

Have we discussed whether that should instead merge the contents of ftl-project-inline-a.toml and ftl-project-inline-b.toml? The configuration manager is set up to operate on multiple configs, so I wasn't sure intuitively whether we want the --config flag to take strict precedence over the envar one, or if the behavior should be additive.

Great job knocking this out in any case!

[safeer]

Thanks @deniseli! I had a conversation with @wesbillman and @worstell, and we all agreed that having the CLI path override the envar makes the most sense, since it's more explicit. I'll hold off until we can talk about it during the sync :)

[deniseli]

Sweet, thanks @safeer! That makes complete sense. I'll go ahead and approve so you aren't blocked on merging. If y'all already talked through it, then it sounds like this is ready to go :)

The only remaining thought I had was whether it'd be useful to log some sort of warning if we happen to override the envar with the flag, in case someone's using the flag without realizing there's also an envar config. That's low enough impact, though, that even if we did want to do that, you are more than welcome to do that in a followup :)

[safeer]

Looks like the override actually happens separately in Kong :)