Enhancement: Add tests and API coverage documentation

[KristofferStrube]

Why?

The wrapper is prone to human errors as it is an interpretation of the Web IDL specifications.
We have already seen such errors e.g. in PR #14. I originally didn't think that I needed to use unit tests for this project as the primary business logic was present in either the JS files or the actual browser API which would make it unsuitable for testing.

What?

What should we then test?
We have already seen that there can be some errors with the serialization because we create some of the objects used for serialization ourselves when objects have special inheritance relations. This should be tested.
We have also seen cases where we had missed special overloads of some methods from the original API. We should go through the Web IDL specifications systematically and ensure that representative methods/properties are present in the wrapper. This will also serve as an overview of which methods from the wrapper represent which methods in the underlying API which is currently not available without some exploration.

How?

• We should test the serialization of option types using some unit testing framework.
• We should ensure coverage of the API with documentation in the form of a table or diagram.

[KristofferStrube]

The first steps towards getting an overview have been created by being able to take a diff between the current WebIDL spec and the spec that we have implemented. This enables us to see which parts we have implemented and enables us to discover changes to the WebIDL specs if they change.

https://kristofferstrube.github.io/Blazor.FileSystemAccess/Status

[KristofferStrube]

We should also add documentation in the form of XML summaries for all public properties and methods in the library.

[KristofferStrube]

Another reason to make that table that maps types/attributes from WebIDL to C# can be seen in release 1.2.0 where we found several naming errors.