Relax component protocol constraint for #1913

This change also relates to #1922. FedRAMP staff have analyzed the
progression of this constraint as it pertains FedRAMP's tailored use of
NIST SP 800-53 controls customized for FedRAMP processes. Previously, it
was believed with a representation of a SSP prior to the "this-system"
component construct that limiting the protocol assembly usage to _only_
components of service type was feasible. However, this does not allow
homogenous this-system-based SSPs to have the same requirement. Moreover
this limits the ability of understandbly different sub-component of
components approaches with complex multi-layered architecture to have
non-service components document their ports and have it filter up into
later transformation and processing by OSCAL-enabled tools. For both
reasons, we recommend removing this constraint. Staff reviewed
historical documentation and believed this constraint to be an
overreach of a previous business rule recommended by FedRAMP staff
during collaboration with NIST.

Author: aj-stein-gsa

src/metaschema/oscal_component_metaschema.xml

@@ -232,8 +232,6 @@
             &allowed-values-component_component_service;
       </allowed-values>
 
-      <expect target="." test="not(exists((.)[not(@type='service')]/protocol))"/>
-
       <!-- ========================================================================================================== -->
       <!-- = TODO: Consider whether INTERCONNECTION constraints are appropriate here.      = -->
       <!-- =       I'm not sure I see a use case for this, but doesn't break to add later. = -->