Harden OTLP `AnyValue`/`TraceFlags` encoding for unsupported/ambiguous types

Spec requirement

Body MUST support AnyValue to preserve the semantics of structured logs (data-model.md:399-400 (permalink)); TraceFlags is defined as an 8-bit byte of bit flags.

Current behavior

exporter/otlp-logs/lib/opentelemetry/exporter/otlp/logs/logs_exporter.rb:328-347 (permalink) (as_otlp_any_value) has no case branch for nil/Symbol/Time/etc., silently producing an empty AnyValue for any unhandled type — e.g. body: nil is indistinguishable on the wire from an explicitly-empty AnyValue. Separately, :314 (permalink) reads log_record_data.trace_flags.instance_variable_get(:@flags), which only works when trace_flags is a TraceFlags object; it silently returns nil for a caller-supplied raw Integer (which is what log_record_data.rb:20 (permalink)'s own doc comment says the field's type should be).

Suggested fix

Add explicit handling (or at minimum a logged warning) for unsupported Body types in as_otlp_any_value, and make the trace_flags encoding branch on the actual runtime type (Integer vs TraceFlags) instead of assuming an ivar-bearing object.

Related rows in SPEC_COMPLIANCE_LOGS.md

DM-1, OTLP-15

Start with as_otlp_any_value and the trace_flags encoding branch in exporter/otlp-logs/lib/opentelemetry/exporter/otlp/logs/logs_exporter.rb, then compare the declared type in logs_sdk/lib/opentelemetry/sdk/logs/log_record_data.rb. Check the referenced data-model.md requirements and SPEC_COMPLIANCE_LOGS.md rows DM-1 and OTLP-15. Done means unsupported Body values are handled explicitly or warned about, and both Integer and TraceFlags inputs encode correctly.