[REFACTOR]: Consolidate service into component #733

Refactor: Unify services as a component type for improved schema consistency

Summary

This proposal seeks to refactor the separate service object definition into the existing component model by introducing service as a new component type. This architectural change would provide greater uniformity across the CycloneDX specification, reduce schema duplication, and simplify tooling implementations.

Background and Motivation

Currently, CycloneDX maintains two parallel object definitions for inventorying assets:

1. Components — used for software libraries, applications, firmware, devices, cryptographic assets, ML models, data, and other tangible or logical artifacts.
2. Services — used for microservices, APIs, function-as-a-service (FaaS), and other network or intra-process services.

Whilst these objects share numerous properties (e.g., bom-ref, group, name, version, description, licenses, externalReferences, properties), they are defined separately in the schema. This separation creates several challenges:

• Duplication: Common properties are duplicated across both definitions, increasing maintenance burden.
• Inconsistent capabilities: Components support identity mechanisms, evidence, pedigree, and hashes, whilst services do not — despite services often benefiting from such capabilities.
• Tooling complexity: Implementations must handle two distinct object types when traversing BOMs, complicating parsers, validators, and analytical tools.
• Dependency graph ambiguity: The dependency object already references both components and services interchangeably, implying conceptual parity.

Current State Analysis

Shared properties between component and service:

Service-specific properties requiring accommodation:

• provider — analogous to manufacturer/supplier
• endpoints — URI endpoints for the service
• authenticated — indicates whether authentication is required
• x-trust-boundary — indicates whether using the service crosses a trust boundary
• trustZone — the name of the trust zone
• data (serviceData) — data flow direction and classification

Component-only properties that services would gain:

• Identity: purl, cpe, swid, omniborId, swhid, etc
• Provenance: pedigree, evidence
• Classification: scope, mime-type, copyright

Proposed Changes

1. Add service to the component type enumeration:

   "type": {
     "enum": [
       "service"
     ],
     "meta:enum": {
       "service": "A service including microservices, function-as-a-service (FaaS), APIs, and other types of network or intra-process services."
     }
   }

This change would additionally leverage #718 to support provider and #638