Add `Review.Fix.createModule`

[lue-bird]

{-| Create a new elm `module` file under a given directory among existing project directories,
see [`Review.Rule.DirectoryKey`](Review-Rule#DirectoryKey).
If a `module` with the same name already exists, the new `content` is ignored.

If you need a different behaviour,
you have to explicitly handle the case where the `module` already exists sepeartely,
allowing you to build context of what's already there and what needs to be added.

-}
Review.Fix.moduleCreate :
    { directory :
        Review.Rule.DirectoryKey
        -- always exists in source-directories
        -- if String, has to be checked + error if doesn't exist
    , content :
        () -> String
        -- Elm.Syntax.File.File doesn't take formatting into account
    }
    -> Fix

This is nice for code generation, for example, where generated code is put in different namespaces which users shouldn't have to touch or create instead of facing an error that requires work that can easily be automated.

[jfmengels]

Can you give some examples on use-cases for this? Would it be for generating code mostly based on usages of some things? I'm slightly worried that it will be hard to notice when there is no need to regenerate the code.

Or are you thinking of purely code-gen related review rules? In which case, we're opening the door to a new usage of elm-review which might be better addressed in a slightly different way (A different review configuration, etc.).

I have also always been worried about with a fix like this about "what if the file already exists"? Since people like to use --fix-all, there is some likelyhood that people accept the prompt a bit too "willy nilly" and didn't notice the somewhat dangerous prompt, which could lead to people losing some work they had been working on and didn't save.

There are also a few security concerns maybe? We don't want people to write weird things anywhere, for instead in the /usr/bin/ folder. I think there are some valid use-cases to write the file to outside the project (in a dist/ folder for instance). I think that we'd need to check whether the file name ends in .elm at the very least.