make sure we're using a current MooseX::ClassAttribute, used downstream by Search::Sitemap
Changed the way services are categorized, fixing a bug found by the USC / SC-CTSI team

Background:
* In eagle-i, a resource "Awesome #2 Pencil" can be of type pencil and can perform technique writing
* Plumage, however, ignores the eagle-i ontology's distinction between resource types (i.e. a noun, like pencil) and technique (e.g. a verb, like writing), and treats the two as the same thing
* So in our example, Plumage would cross-list "Awesome #2 Pencil" under both "pencil" and "writing"
* However, the eagle-i ontology has a very shallow and unhelpful type ontology for services, where a wide range of resources need to get categorized under generic top level types like "Analysis service" or "Materials analysis service" -- which no researcher is likely to want to search under
* So in our example, this would be like listing the "Awesome #2 Pencil" as type "object" and technique "writing" ("object," like "service," appears too generic to be very helpful)
* At UCSF, we decided that by policy, every resource of a type "* service" would be listed with a corresponding technique (so it shows up under the technique on a Plumage site), and that we'd hide it under the service category, and we hard-coded this local logic into the Plumage code
* However, for USC, every item of type "* service" didn't have a corresponding technique, so they were essentially being hidden

Change:
* Now, the code always adds to the original type group, except in cases where the resource is of type "* service" and there's a corresponding technique listed
* Continuing the previous analogy, that means if our "Awesome #2 Pencil" is only listed under a uselessly broad type (like "Object") but is associated with a useful technique like "Writing," then it would show up only under "Writing" and not under "Object"
updated package version number to 0.91