Add optional `devDependencies` field in `vessel.dhall`

[rvanasa]

This PR introduces the ability to specify local "dev dependencies" (well-known from Cargo and npm) for a Vessel package.

Here's a concise explanation of dev dependencies from Rust by Example:

Sometimes there is a need to have dependencies for tests (or examples, or benchmarks) only. These dependencies are not propagated to other packages which depend on this package.

As a response to https://github.com/dfinity/vscode-motoko/issues/66, this feature would provide a simpler alternative to the ./vessel.dhall + test/vessel.dhall pattern used in various official and community repositories (e.g. motoko-base). The goal is to improve readability for both humans and development tools (especially IDE integrations).

This PR also make it possible to omit fields in a vessel.dhall manifest. For instance, it's no longer necessary to write verbose default values such as compiler = None Text, which I expect will be appreciated by the community. :)

[rvanasa]

A few points of discussion:

By switching to a single vessel.dhall file, it would be possible to accidentally include transitive dev dependencies in the package itself, leading to unexpected downstream compile errors.

• One solution could be to provide a Vessel package linter which detects these mistakes as a pre-commit hook or IDE integration.
• This would be a major UX improvement over the current multi-vessel.dhall pattern, especially for environments using node-motoko such as the VS Code extension. (Edit: this project layout is now supported in the VS Code extension)

Vessel originally used strict type checking for Dhall files, which means that this PR (and any other change to vessel.dhall or package-set.dhall) is necessarily backwards incompatible.

• Fixing this takes two lines of code, but any version <= 0.6.4 would be unable to parse Dhall files with new fields (such as devDependencies).
• Perhaps we could combine this with some additional improvements and make this into a "Vessel 1.0" release?
• We could also use this as an opportunity to simplify installation and updates by switching to a new distribution method (such as dfx, an npm package, and/or bundling into the Motoko VS Code extension).

[matthewhammer]

... necessarily backwards incompatible.

Bummer.

Perhaps we could combine this with some additional improvements and make this into a "Vessel 1.0" release?

I'm supportive of that.

We could also use this as an opportunity to simplify installation and updates by switching to a new distribution method (such as dfx, an npm package, and/or bundling into the Motoko VS Code extension).

I'm also supportive of these other distribution methods.

I think dfx (or whatever packages the compiler in each context) makes the most sense to me. It never made sense to me to separate the package manager and the compiler as much as they've been separated thus far.