## Changes

Change the type of `Resource` to reference the definition in the SDK so
that the resource's scheme URL is included in logs data model.

## Why

The Logs Data Model misses scheme URL of resource. All of the languages
reuse a common type representing resource.
- Java (stable logs): [reuses a common resource
type](https://github.com/open-telemetry/opentelemetry-java/blob/main/sdk/logs/src/main/java/io/opentelemetry/sdk/logs/data/LogRecordData.java)
- .NET (stable logs): [reuses a common resource
type](https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.OpenTelemetryProtocol/Implementation/OtlpLogRecordTransformer.cs)
- C++ (stable logs): [reuses a common resource
type](https://github.com/open-telemetry/opentelemetry-cpp/blob/main/sdk/src/logs/read_write_log_record.cc)
- Python (experimental logs): [reuses a common resource
type](https://github.com/open-telemetry/opentelemetry-python/blob/main/opentelemetry-sdk/src/opentelemetry/sdk/_logs/_internal/__init__.py)

These changes can be seen as breaking. However, there is 100% precedence
of how log attributes and resource are currently handled in all
languages. I see the current description as a bug because we would miss
scheme URL of the resource. AFAIK the intention of the OTel Logs
Specification authors was to have only nested values for Body and
Attributes.

Related PRs:
-
open-telemetry#2888
- open-telemetry/opentelemetry-go#4809