Support project.yaml

[josephjclark]

At the moment the plugin is focused around workflow.json, and tracks the project from that.

But it's probably more typical for a project to have a project.yaml file which is the primary source of truth. A project.yaml may have several workflows inside it.

It's probably still valuable to track a workflow.json. So maybe what we want to do is:

• look for a project file. Look for project.yaml first, workflow.json second
• maybe later we can be driven by .openfnrc if there is ambiguity

I don't think we need to support multiple project files in a single folder. Let's cut cloth on that for now - you can assume just one project root, which will be a yaml or json file.

I suspect the Workflows view should be renamed to Project view, and maybe later can include some metadata from project.yaml

[josephjclark]

Note to me:

The objective here is to make the extension seamless with CLI deploy and Github Sync (which both use project.yaml and state.json)

[josephjclark]

Reasons for hesitation on this:

1. I think we need a common module in kit which builds a model of an openfn project. This can be re-used by the VSC extension and the CLI. Basically if we have one module which is really good at understanding the filesystem, we can re-use that module in a few places
2. I'm thinking of a radical restructure of project.yaml. But I suppose even I do this, I'll need to support the "legacy" format.