What and why?

This PR renames the RUM Operations API for consistency and clarity, and introduces a new generic parameter options: OperationOptions? to make the API extensible and avoid coupling the public interface to a single feature (profiling).

Before:

func startFeatureOperation(name: String,operationKey: String? = nil,attributes: [AttributeKey: AttributeValue] = [:])
func succeedFeatureOperation(name: String,operationKey: String? = nil,attributes: [AttributeKey: AttributeValue] = [:])
func failFeatureOperation(name: String,operationKey: String? = nil,reason: RUMFeatureOperationFailureReason,attributes: [AttributeKey: AttributeValue] = [:])

After:

func startOperation(name: String,operationKey: String?,attributes: [AttributeKey: AttributeValue],options: OperationOptions?)
func succeedOperation(name: String,operationKey: String?,attributes: [AttributeKey: AttributeValue])
func failOperation(name: String,operationKey: String?,reason: RUMFeatureOperationFailureReason,attributes: [AttributeKey: AttributeValue])

How?

• Introduces OperationOptions protocol in DatadogInternal as the extensible options type for operations.
• Introduces ProfilingOptions (conforming to OperationOptions) to carry the profiling sample rate.
• Updates RUMMonitorProtocol, its default implementations, Monitor, and NOPMonitor accordingly.
• Updates API surface files to reference the new API naming

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes
• Add Objective-C interface for public APIs - see our guidelines (internal)
• Run make api-surface when adding new APIs