Use Notification struct + Type impl for Notifications

[TTWNO]

The quickly-slapped together, but well tested ;) #125 was merged recently. This added notification reading support. Although this is exciting, I'd like it in a better state: a big list of random, unnamed fields in a tuple is not an ideal way to be deconstructing the message body.

We should have a Notification struct which implements Type instead, giving us access to all properties, along with their names.

This will require some additional work, especially related to how to (de)serialize key names in the receiving HashMap; ideally, we'd like to be able to deserialize this as an enum containing its internal data, like so:

pub enum Priority {
    Low
    Medium
    High
    Critical
}
#[non_exhaustive]
pub enum Hints {
    Priority(Priority),
    ...
    Other((String, OwnedValue))
}
pub struct Notification {
    app_name: String,
    body: String,
    hints: Vec<Hint>,
    ...
}

That will give us a much more flexible notification module.

[albertotirla]

for most of what you're saying, this commit covers it. Hints and afew other things weren't implemented there, but at the time, I believed, and somewhat still do, that it's out of scope. The only reason for the odilia-notify crate existing is to serve the needs of odilia when it comes to capturing notifications. I rejected that particular commit though, for the reason outlined above, and also because I thought it would add more bloat. In any case, work from this can begin by either reverting the commit after it, or cherry picking the commit I just linked and solving merge conflicts. The rest of what you said, aka hints as enums and other such things, can continue from there.