Upgraded project to target the newest Blazor.FileAPI version.

[KristofferStrube]

In this PR, my goal is to upgrade Blazor.FileSystem to use the newest version of Blazor.FileAPI and thereby also the newest version of Blazor.WebIDL, which has changed how we ensure that IJSObjectReferences are disposed.

As a part of this, the PR ensures:

1. That wrapper types implement IJSCreatable (and thereby IJSWrapper).
2. That we don't use reflection for mapping enums.
3. That all public types are documented with XML Documentation.
4. That IJSWrapper types implement IAsyncDisposable.
5. That IJSWrapper types dispose of their reference when we construct them in the library.

[HarvieKrumpet]

Is it possible for your filepickers to provide the full path to the file/s the user has chosen? In many cases, it is not the actual filestream. but to provide the path to the underlying server so that it can perform some heavylifting on that file. I only receive the filename.ext. In this situation, the pure filepicking, "is" the desired functionality. this is passed via signalr down to the localhost server to perform some functionality not possible in blazor/wasm and sends back up the results to the client. for AI work. Currently I have to pre-feed Blazor the root paths and have the server "getFiles" on the file name.

[KristofferStrube]

Hey @HarvieKrumpet, no, sadly, that is not possible with this API.
I recommend reading sections 5 and 6 of the spec to learn about some of the considerations the implementors had, which is why this is not possible.

[KristofferStrube]

This has been merged. I will make a description of all the changes in the CHANGELOG, then release an alpha version to build Blazor.FileSystemAccess on so that I'm sure that they work together with the new changes.