Ookii-dialogs-wpf: ProgressDialog should implement IProgress<T>

Thanks @vpenades, that sounds like a great idea.

Let me know if you'd like to take a stab at it and send a PR, otherwise I'll get to it soon for the next release.

PR ready...

@vpenades Ookii.Dialogs.Wpf now supports .NET 5 as well as .NET Core 3.1, so I thought I'd ping you in case you ever want to start discussing possible improvements to the IProgress<T> implementation

ps: Don't feel obligated to reply. This is just a friendly ping given your prior interest in this.

The use case most of the times is going to be background tasks initialized with an Object value that can be cast to multiple versions of IProgress<T> so they can report back the progress of the backgrond task.

I think the interface is not widely used because it's not very well known, but since IProgress<T> exists from quite some time, I did a small search to see how people is using it, and I found:

```C#
IProgress // progress reported in values between 0-1
IProgress // progress reported in values between 0-100

It is very tempting to have a structure that keeps all the information required by the progress dialog (percent, text, description), but this _must be avoided_  because that would mean the caller needs to fill that structure, which would force it to have a dependency on the ookii library, this is probably not desirable for background tasks, or pure code libraries that don't want to depend on an UI library.

So, in order to pass rich progress information, we need to use only BCL types and collections. Unfortunately, `IProgress<T>` does not define a standard....   but in general I guess everybody will expect (int Percent, string Text, string Description)

So, I would propose adding these interfaces:

```c#
IProgress<float> // by far, the implementation I've found most occurences searching on github.
IProgress< KeyValuePair<string,object> > // where key is the name of the property to set (percent, text, desc)

Additionally, the current IProgress<INT> and IProgress<STRING> could cache the content so they're not mutually exclusive; the current code already caches the progress, but it should do the same with the text. So a background task could call these interfaces consecutively without loosing the value set by the previous call on the other property.