Refactors the S4 class structure for meta elements

[hlapp]

This makes the "meta" class, formerly the multiple inheritance subclass, the new superclass of both LiteralMeta and ResourceMeta. The former superclass, "Meta" is eliminated.

This move solves several problems, while avoiding a potential host of others. Specifically:

• As the subclass of both LiteralMeta and ResourceMeta, it was essentially a class for meta instances that didn't know what they were (because if they did, the could have been instances of either LiteralMeta or ResourceMeta). This was primarily useful for converting from XML to the corresponding class instance, without having to have the logic for determining which meta class is the right one in every place where such a conversion is needed. This change maintains that benefit of the "meta" class, but while possible makes it generally a bad idea to instantiate it directly (because it has neither LiteralMeta's nor ResourceMeta's slot, as opposed to having both of them.
• The meta class is widely used, not just for conversion from XML, but also for type testing because the meta() constructor function mostly created instances from this class instead of from the specialized LiteralMeta and ResourceMeta classes. As a result, this may have come to be used by clients as well. This change keeps those tests (and conversions) working, even when the constructor function is refactored to instantiate the correct specialized types.
• The Meta class wasn't really used anywhere, and likely isn't used by any clients either. Eliminating it should have little to no adverse consequences.

In addition to the meta class hierarchy, the meta() constructor function is also refactored to try hard to determine the correct type, while also being careful not to overwrite a type that was provided to the call. This will in fact allow a client to create and provide their own metadata class (if they make it inherit from meta or one of its subclasses).

[cboettig]

@hlapp this looks good to me. I think if we just deprecate the simmap vignette and tests as discussed in #201, the checks should pass (?). Then just go ahead and merge #201 & #203 when you are ready.

Also, just a note that #199 looks ready to merge, though in my opinion it would be worthwhile to just make simplify=TRUE the default behavior first. What do you think?

[hlapp]

I think I have a fix for the remaining failure here. I also have an alternative to #201 in the works which would keep the class names. I think I'm at the point where everything passes, just need to document and package it up for a PR.

Also, just a note that #199 looks ready to merge, though in my opinion it would be worthwhile to just make simplify=TRUE the default behavior first. What do you think?

I'm holding that one until after the class name issue is addressed. That's because #201 would make an easy provision to make it the default, and in fact going back to old behavior would be more involved.

[hlapp]

Yay, finally we have a passing test suite now here too. @cboettig I'll take your comment above ("this looks good to me") as approval to merge 😃