Move to netstandard2.0 only and decouple from RProvider for now

[zyzhu]

Currently Deedle and Deedle.Math targets both netstandard2.0 and net45. The reason of keeping net45 is to keep Deedle.RProvider happy as RProvider has not been moved to netstandard2.0 yet.

However, it becomes more and more painful to manage the build tool chain. Lots has been changed in FSharp.Formatting and FAKE. To use the latest versions of them while maintaining net45 target cross platform becomes impossible.

To get RProvider working on netstandard2.0 is a daunting task as I still do not have time to learn the mechanics of type providers. It is also stuck at R3.4.2 until this PR can go through.

Back in the day on Twitter (https://twitter.com/tomaspetricek/status/1192830586576084992). @tpetricek agreed that it's ok to keep RProvider separate as it's quite niche.

I will move Deedle and Deedle.Math to netstandard2.0, Deedle.Excel to net461 and figure out how to use the latest fsdocs to update documentations. I'll keep this issue open until we can link Deedle with RProvider again in the future.

[siavash-babaei]

Apparently RProvider is being updated to run on .NET 5.0 and later.

Maybe Deedle could do the same. Deedle.RPlugin can be updated later accordingly when RProvider passes beta.

Currently 4-5 projects on FsLab and this is probably the most important one along with FSharp.Data providing a great toolset to import and manipulate data. Hope at least these get the necessary attention and updated for latest .NET compatibility.

Surely, there will be performance gains, better code, and easier maintenance cycle once updated. The .NET 6.0 is obviously going to be more streamlined and performant, less bug prone, and better in every way than Standard 2.0 ...

[zyzhu]

Once RProvider is stable, it's definitely worth reviving Deedle.RPlugin and move it to .NET 5.

I'm afraid my hands are quite tight recently. Contributions in this endeavor is definitely welcome.