Cleanup build artifacts in Fable 3

[ncave]

This is a discussion on the best approach to clean up build artifacts in Fable 3.

Although it greatly simplifies the build to just create output files with extension .fs.js right next to source files, it is polluting the source folders by sprinkling those compiled artifacts all over the place (including potentially .nuget packages).

So far I see two ways of dealing with that:

• Collect the list of created artifacts so they can be deleted afterwards at later stage.
• What fable-splitter and fable-compiler-js were doing before, generate files in an output directory and modify their import references so dependencies can be properly referenced from the output folder.

[alfonsogarciacaro]

Yes, this is a controversial change, so I should have opened a discussion beforehand, sorry. I've been recently using Bucklescript, which does a similar thing and at first I was also displeased how the repository was being polluted, but after a while I got used to it and I could see some advantages, so I wanted to try it in nagareyama:

• It makes it easier to relate the F# and JS code, which is something we want to improve for debugging as we don't have source maps now.
• It saves trouble both for us and the users to think about how the directory structure changes in outDir. This was not consistent between fable-splitter and fable-compiler-js and it required some hacks (like the "{$entryDir}" and "{$outDir}" macros). Probably we shouldn't edit the import sources anyways, the Typescript team for example considers them as immutable identifiers.
• For most users, Fable will just be the first step in a build pipeline, so the next tool (usually a bundler) can take care about moving the generated code in a dist folder or so.

About cleaning, we can add a clean command to Fable that removes all ".fs.js" files.

About the .nuget packages, fable-compiler-js should probably do the same thing as Fable.Cli and copy to the sources to the ".fable" folder. This is necessary anyways for proper resolution of npm packages. Somewhat related, I was also planning to precompile packages (on first use in the client machine, not for distribution) and avoid having to collect all the sources into a single project as we're doing now. Hopefully this will become possible once dotnet/fsharp#9510 is ready and we don't need to inline functions to resolve SRTP.

[ncave]

Closed with #2175