Discriminate between attributes in different namespaces

[tombailo]

This commit is an alternative approach to fixing #13 (Attribute namespaces are not preserved), inspired by the discussion on #33. It changes the type of the attributes map on the Element struct from a String -> String map to an AttributeName -> String map. AttributeName is a re-export of the xml::name::OwnedName type in xmltree-rs, which is a struct containing the attribute's local name, namespace and prefix.

It is possible to search the attributes map using a fully initialised AttributeName structure, but for convenience get_attribute(), get_mut_attribute() and take_attribute() methods, modelled on the *_element() equivalent are provided, which take an AttributePredicate. Ready-made implementations taking either a local name or local name + namespace are provided.

This is a semver-breaking change, hence version is incremented to 0.11.0, I'm not sure if it is necessary to provide some kind of backward-compatibility compile time switch?

I was in two minds as to how closely to follow the pattern of the existing take_element(), get_element() etc. APIs. While writing the tests I realised that those APIs do not allow you to pass None for the namespace, you can either pass just the local name, and ignore namespace, or local name + namespace. This means it's not possible to explicitly search for elements with no namespace, which seems like a defect to me.

My initial implementation, which I still have on a branch, had implementations of the AttributePredicate trait for String, &str and Cow<&str> just like the the Element equivalents, but having these and an implementation for (N, Option<NS>) to allow the namespace to be specified means that if you want to pass None the type is ambiguous so you have to specify which string-like type you mean, e.g. <Option<String>>::None. This seemed quite awkward so this version only supports &str. I can of course change this if required.

[tombailo]

@ctrlcctrlv I had a go at implementing what Sebastian suggested on your PR, I'd be interested to know if this meets your requirements as well

[ctrlcctrlv]

I wonder if we can't somehow wrap AttributeMap (i.e. make it a real struct instead of an alias, even if it's just a newtype struct) which would make this change less painful for downstreams. If we did that, we could (I think, running on fumes here):

trait IntoAttributeKey {
    fn into_attribute_key(self) -> AttributeName;
}

pub struct AttributeMap<K: IntoAttributeKey, V>(AttributeMapInner<K, V>);

impl<S: AsRef<str>> IntoAttributeKey for S {…}

That was my main concern with taking a similar approach in #33.