Session-based sampling doesn't consider Events/Logs

In addition to the sampler problems identified in #841, the current approach within SessionIdRatioBasedSampler assumes that telemetry is entirely still span-based, which is no longer the case.

We need a means to expand/enhance the current approach to also account for LogRecord sampling. Currently, there isn't a single mechanism to do this like in tracing, but there are a couple of options.

Option 1: We could somehow, through customization, wrap the upstream SDK LogRecordBuilder with a session-aware sampling decision. If sampled, then emit() would simply delegate, and if not sampled, then emit() would effectively be a noop.

Option 2: We could create a custom session-aware sampling LogRecordProcessor that is ahead of the upstream SDK BatchLogRecordProcessor.

Both options are not optimized and unfortunately consume memory/cpu where it shouldn't be necessary.

Start by reading the SessionIdRatioBasedSampler implementation and the context from issue #841, then inspect the upstream LogRecordBuilder and BatchLogRecordProcessor APIs. Compare the two proposed approaches for applying session-aware decisions to LogRecords; done means the chosen design accounts for Events/Logs sampling without the unnecessary memory and CPU costs identified here.