Fix #86 by adding options for inclusion of metadata in output.

            report.OutputInstanceGenerator = false;
            report.OutputTaxonomyVersion = false;
            report.OutputXmlDeclaration = false;
            report.OutputComments = false;

Fix #85 by checking for null Scenario during comparison

Fix #84 by adding new overload for Report.FromXml, remove code related to ESEF validations, added empty XML documentation comments, conversions between flavors, etc.

After starting to add support for xBRL-JSON it became obvious that the code needed restructuring.
So 3.0.0 comes with breaking changes to the naming and organizing of code.
Different flavors are now in their namespaces Diwen.Xbrl.Xml, .Inline, .Csv, .Json,
Diwen.Xbrl.Instance is now Diwen.Xbrl.Xml.Report and so on.
Test code was also similarly shuffled.
Functionally everything is still the same, performance wasn't affected etc.
Please get in touch if you can't find something, or you if have questions or comments.

• Target .NET 8
• Some refactorings to xBRL-CSV functionality

1. This release adds support for xBRL-CSV reading, writing and conversion to/from xBRL-XML. As I only had EBA 3.2 material available for testing, it very likely won't work with other reports. This can be helped if get other material to test with (should include both formats for comparison)

2. There is also a change to default functionality! By default, when loading an xBRL-XML instance, duplicate facts are removed! This can be changed with a parameter. Most important reason for this was that some of the test reports I use had duplicate facts, which made testing harder is they weren't removed. Also I figure the business case for wanting the duplicates is less common than needing them removed. I am open to discussion about this if needed.

3. I am very likely going to create a new 2.x branch which will be based on .NET 6/7+ (ie. drop support for .NET Standard and .NET Framework) The 1.x version won't get new features or optimizations etc. (like xBRL-JSON support which I'm planning to start on)
   This is because the .NET Framework application this library was initially created for is nearing the end of its lifecycle, and with it the only application that I actually know that uses this library. One of the points of this library is that it is "standalone", doesn't have any dependencies. As .NET Standard doesn't have support for eg. System.Text.Json, this looks to be very limiting going forward. This change will also make life easier with linux, vscodium, and other tooling. Again I am open to discussion.

Bug with namespaces used in the value field of a segment explicit member #76

Fixes and changes to handling of IXBRL. Possible breaking changes due to namespaces.

Fix bug #66 with handling default namespace and units

Fix #74 Unused namespace 'xbrldi' for instance with no explicit or typed members