AbstractItdMetadataProvider should permit more flexible class-level downstream dependency resolution

Currently AbstractItdMetadataProvider supports dependency registrations where the downstream is:

• "Instance-specific", meaning the target downstream MID for a notification is known in advance and presented as part of the metadata notification from the MetadataDependencyRegistry.

• A "null" downstream dependency can be presented via a generic listener and handled by the new ROO-1882 mechanism. However this approach means all metadata events in the system pass through the MetadataProvider, which is inefficient if only a particular subset of known-in-advance metadata notifications are desired.

• A "class-level" downstream dependency (of the MetadataProvider.getProvidesType()) if and only if the upstream dependency is a PhysicalTypeIdentifier notification. In this case the AbstractItdMetadataProvider unwraps the upstream notification's MID (ie a PhysicalTypeIdentifier) and converts it into a local MetadataProvider instance-specific MID.

Sometimes it is desirable to "listen" for all metadata notifications of a particular type, just as we do for PhysicalTypeIdentifier. If every metadata notification will pass to an instance-specific MID, the first approach listed above works fine. If the upstream metadata is a PhysicalTypeIdentifier, the last approach above will accommodate it. However, it is not presently handled if the upstream is a non-PhysicalTypeIdentifier and the downstream is not instance-specific.

We should add a new method to AbstractItdMetadataProvider that subclasses can override to resolve a class-level downstream into an instance-specific downstream if the third scenario above is occurring. The AbstractItdMetadataProvider code should handle the PhysicalTypeIdentifier use case and be available for super() calls if desired.