Support AdaptiveProgressBar

[polarathene]

Thanks for working on this crate, it was really helpful as a reference to use the Windows crate to produce a toast notification with progress bar added :grinning:

Would you be interested in a PR to upstream the support?

---

I was also playing around with refactoring a bit by using structs instead of a single method with format string, out of the various XML serialization crates, strong-xml seems to be a decent one (you can use a Vec of enum structs, as opposed to individual Vecs of each struct as their own fields on the parent struct; both yaserde and quick-xml seem to work that way). The XML template can then be serialized, which seems better to maintain than the current approach?

I also am looking at having the notification manager split out as it's own struct instead of creating an instance for it each show() or similar call (in my case I wanted to update the progress bar toast, which requires providing a tag and optional group as well).

Likewise, for the progress bar updates, bindable strings are needed. This wasn't well documented, but the C# implementation source reveals the "magic" is just changing the string value to reference a hash map key wrapped between { }. We then create a NotificationData instance with a StringMap (effectively equivalent to rusts HashMap) and add the keys with values there. Updates can be applied to that same StringMap or a new instance of just the changed values, wrapped in a new NotificationData instance, with the sequence number incremented and the notification manager update method called.

---

I'm not too experienced with using Windows Toasts, so I'm not sure how important it is to have control customizing the binded string var names, I assume you'd only have the one instance and that we don't have to match the API support of other implementations/docs?

The official docs for AdaptiveProgressBar in Toast XML schema list fields supporting different types, but for the most part value for example is always a string (a number, indeterminate, or a {binding_key}). We're only interested in serializing a string value, so impl Display can check for is_indeterminate bool to override the actual value if true, and otherwise return the binding name (probably makes sense to default to that?).

XML serialization aside, a separate method would be needed to get a binded value to add/update in the NotificationData StringMap. I'm still giving this some thought on how to approach.

---

Is the above a bit overkill to contribute to this crate? Would you prefer to just add an XML template snippet with the current approach you use? Toast updates still require NotificationData with StringMap and tag though.