Support both osgi.bundle and osgi.fragment resource types when given a Subsystem-Content header clause with an unspecified type attribute.

Before ARIES-1368, the Subsystems implementation would not distinguish between bundle and fragment content. This created the following issues as discussed in that bug:

(1) Content would not be found when the Subsystem-Content header was computed by the implementation and fragments were provided by a remote repository.

(2) Content would not be found when the Subsystem-Content header was specified and contained a resource with type osgi.fragment provided by the local repository.

However, it did not cause issues when, for example, fragment content was included as part of the header without specifying the type, and the fragment also existed within the local repository.

Unfortunately, the bug lived long enough to become an issue for consumers with a zero migration policy. Consequently, we would like to introduce the following implementation specific behavior without violating the specification.

REQUIREMENTS

(1) An unspecified type attribute in a Subsystem-Content header clause MAY indicate either a bundle (i.e. osgi.bundle) or a fragment (i.e. osgi.fragment).

(2) When the type attribute is not specified, the implementation MUST search for both bundles and fragments according to the rules for discovering content resources in section 134.5.5 of the specification.

(3) Bundles MUST be preferred over fragments.