Changing how we handle attributes: newattr branch

[Richard Schwarting <aquarichy gmail com>]

Adam Ples' patch for XPath wanted to use xmlAttrs and GXml.Attrs the same way we use xmlNodes and GXml.Nodes; in that most GXml nodes have a corresponding libxml2 node that they map to. 

GXml.Attrs didn't follow that in part because setting attributes in libxml2 is mostly done by strings (xmlSetProp) and because I thought I didn't want to implement NamedNodeMap. 

Anyway, I thought that Adam's idea was reasonable, especially because if we did, and if we had a NamedNodeMap too, then we could get rid of the GLibHashTable that I was using to store GXml Attrs in, which ended up requiring ugly and error prone synchronisation between GXml and libxml2 every time you wanted to see what the XML document actually looked like (saving/stringification).  And because then Attr.vala would be a bit smaller (yay).

So, there's the newattr branch in git now.  Everything should behave the same except:

GXml.Node.attributes has changed type from a GLib.HashTable to a GXml.NamedAttrMap (which implements GXml.NamedNodeMap<Attr>).

Does anyone have any objections to this?  The consequence for users is that instead of getting GXml.Node.attributes and doing lookup (), size () and insert (), etc., on it, they'll use get_named_item (), length, and set_named_item (), which are the methods that the W3C DOM specifies anyway.  Let me know if you think convenience functions that mimic GLib.HashTable's common used ones would be a good idea (so a developer would just change the type, but not their calls, since we'd have a GXml.NamedNodeMap.lookup (), etc.)

There are a bunch of other API breaks from the summer, so I don't think another one will be the end of the world.

If there aren't any objections, let me know and I'll try to merge it next weekend.