Add convenience command for setting up a new subpackage

[JordanMartinez]

Related to #1136, add a new command that sets up a subpackage. In other words, calling spago subpackage add <packageName> sets up the following:

• creates a directory: ./<dir-name>/.
• sets up a single purs file in ./<dir-name>/src/<file-name>.purs with content: module <module-name> where\n
• sets up a spago.yaml file
  • package-name: the package name
  • dependencies - same as those used in spago init

For CLI args, I think we should support only 'additive' flags/args. So, a default subpackage is set up and one can further add to it with flags, but options to remove anything are not supported. This prevents bugs caused by an additive option and destructive option appearing simultaneously that otherwise conflict. In other words, the purpose of this command is to generate boilerplate and then let a user modify each part as needed, not to support all possible options on the CLI.

Keeping it small, here's what comes to mind:

• --dir-name - the name of the directory to use here: ./<dir-name>/. When unspecified, uses the package-name.
• --file-name - the name of the file to use here: ./<dir-name>/src/<file-name>.purs. When unspecified, we use the package name by converting foo-bar into FooBar.
• --include-tests - a .<dir-name>/test/Test/<file-name>.purs file is generated and with same content as spago init's test code and a corresponding test config in spago.yaml. When unspecified, a test dir and config section is not included.
• --module-name - the file generated in src (and test if --include-tests is set) use this module name (e.g. module <module-name> where). When this value is unspecified, uses a derivation of the package name (e.g. foo-bar -> FooBar).

[f-f]

I think it's good to have something like this, but I'd like to have it under spago init --subpackage PKG.

And we can likely start with a smaller amount of flags, in the sense that I think there's little point to fix these things for the user since they are a file edit away. I'd only keep --directory, derive everything else from the package name, and include tests anyways (like spago init does)

[JordanMartinez]

Works for me.

[flip111]

Is an additional type with name SubPackageConfig needed? Similar to PackageConfig here https://github.com/purescript/spago/blob/master/core/src/Config.purs#L72-L81

The init commands takes the command line args and puts those in the PackageConfig https://github.com/purescript/spago/blob/master/src/Spago/Command/Init.purs#L48-L50 to support a subpackage something is needed here. How should it be modeled?

[f-f]

We won't need any new type, the PackageConfig supports everything we need - subpackages will only need their withWorkspace set to Nothing