Implement compiling with .csproj input.

[Drake53]

As requested in #17
This uses the Cake packages to read a .csproj file and obtain its project- and packagereferences.
The way this enumerates over .cs files could still be improved. It currently assumes that all .cs files (except the ones in bin and obj) are compiled.
It also reads packages using NuGet.Packaging. This allows it to enumerate over .dll files, so you do not have to manually add them with the libs argument.

[yanghuan]

Thank you very much for providing the rigorous code.

I thought about it carefully, it might not be appropriate to support loading .csproj, CSharp.lua is just a compiler, like csc, gcc, etc. rather than a completecompilation system, like msbuild, cake, cmake.

.csproj may rely on other .csproj projects, making sure compilation is correct is a bit complicated.

You will all rely on the .csproj engineering code, compiled into a module may not be suitable for some people's needs, each .csproj compile a module.

It's nice to use NuGet.Packaging to get dll, but dll may not have downloaded to the local disk yet, like dotnet core sdk processing .csproj restores and downloads dependent dll.

The third-party libraries previously relied on by the project were Microsoft.CodeAnalysis.dll and Microsoft.Code Analysis.CSharp.dll, and now add 10 extra dlls, which is somewhat less economical.

The .csproj file also contains some csc compilation parameters, which may also need to be handled

In summary, supporting .csproj is a bit complicated, and it may not be necessary to consider it from a compiler's point of view.

I'll modify the -s parameter to allow a list of source code to be passed.

[Drake53]

I understand that supporting .csproj may not be part of your vision for CSharp.lua.

It's true that correct compilation using .csproj files is very complicated. Right now the code only reads the .csproj files to find references to other .csproj and packages. So it only cares about the ProjectReference, PackageReference, and TargetFramework(s) properties, and ignores everything else. After that, it basically behaves as if the folder containing the .csproj was passed as input.

It's also true package restore is not implemented, so the dll may not be downloaded yet. For my own use case, this is not a problem, because I add a dependency on the .csproj that I pass as input, so visual studio automatically runs package restore for me. I will try to implement this later.

It's true that I added around 10 more dependent dlls by using the Cake and Nuget packages. The nice thing about reading .csproj though, is that you no longer need to pass them all with the -l parameter.

I understand if supporting .csproj is not something you want to do. I respect your decision. Thank you for taking the time to consider it.

[yanghuan]

Thank you for your understanding.
I've tried to support .csproj use msbulid package too, found a lot more trouble than thought, and also introduced too much dependency. If roslyn has a simple api to solve, I'll still consider it.