Ookii-dialogs-wpf: ProgressDialog debería implementar Progress<t/>

Gracias @vpenades , suena como una gran idea.

Avíseme si desea intentarlo y enviar un PR, de lo contrario, lo veré pronto para el próximo lanzamiento.

PR listo ...

@vpenades Ookii.Dialogs.Wpf ahora es compatible con .NET 5 y .NET Core 3.1, así que pensé en hacerle ping en caso de que alguna vez quisiera comenzar a discutir posibles mejoras a la implementación IProgress<T>

PD: No se sienta obligado a responder. Este es solo un ping amistoso dado su interés previo en esto.

El caso de uso la mayoría de las veces será tareas en segundo plano inicializadas con un valor de Objeto que se puede convertir en múltiples versiones de IProgress<T> para que puedan informar el progreso de la tarea backgrond.

Creo que la interfaz no se usa mucho porque no es muy conocida, pero como IProgress<T> existe desde hace bastante tiempo, hice una pequeña búsqueda para ver cómo la usa la gente y encontré:

`` C #
IProgress// progreso informado en valores entre 0-1
IProgress// progreso informado en valores entre 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)

Además, los actuales IProgress<INT> y IProgress<STRING> podrían almacenar en caché el contenido para que no sean mutuamente excluyentes; el código actual ya almacena en caché el progreso, pero debería hacer lo mismo con el texto. Por lo tanto, una tarea en segundo plano podría llamar a estas interfaces de forma consecutiva sin perder el valor establecido por la llamada anterior en la otra propiedad.