Normalize config file handling

[granicz]

Some build scenarios are not currently handled using wsconfig.json (we need new features) and some scenarios are handled incorrectly or in a confusing way (we need fixes.) An example for the former would be two or more WebSharper projects over the same source folder/files, which currently would get reconfigured by a single wsconfig.json as opposed to each project being able to specify their own configurations in different config files. Some of this has been addressed in the #1084 quick fix ticket, however more changes are needed. An example for incorrect/confusing operation would be a project file specifying one thing and a config file specifying another, and the log output showing the executing command line as per the project file and not the combined configuration, making debugging (edge cases) on argument handling nearly impossible.

This ticket outlines the desired config file handling. Ground rules should be:

1. Builds executing via msbuild/dotnet, thus with computed configurations (ie. with external configuration files; see config precedence rules below), should receive command line arguments to the compiler that correspond to net effect of those configurations. This means that underlying compiler invocations should correctly receive the full, configured set of build arguments.

2. Configuration precedence should follow the standard .NET convention, ie. enablle configuration through the following layers: a) settings in the F# project file, overridden by b) settings in wsconfig.json, if exists, overridden by c) settings in wsconfig.{project-name}.json, if exists.

[granicz]

The first example I gave above is problematic with .NET Core, for instance, a single project.assets.json gets in the way.