opentelemetry-sdk: unify logging force_flush timeout defaults to 10000ms

[avinab-neogy]

Description

Fixes #5403

Aligns all force_flush timeout defaults in the logging SDK to a single value (10_000ms),
matching the exporters (LogRecordExporter, ConsoleLogRecordExporter, InMemoryLogExporter)
and the OTLP log exporters, which already used 10_000. Previously the logging module split
5×30000 / 3×10_000 across different processors/exporters.

Also changes BatchLogRecordProcessor.force_flush to require timeout_millis: int instead of
accepting int | None, so its signature matches the abstract LogRecordProcessor.force_flush
it implements — the rest of the hierarchy never accepted None.

Opened as draft: pending confirmation from @carlosalberto on whether 10_000 (vs. 30000,
to match traces) is the right target value, and confirming logging-only scope.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

• pytest opentelemetry-sdk/tests/logs/ -q — 111 passed, no regressions
• Ran locally on Python 3.10.12 against the modified source (editable install)

Does This PR Require a Contrib Repo Change?

• Yes. - Link to PR:
• No.

Checklist:

• Followed the style guidelines of this project
• Changelogs have been updated
• Unit tests have been added
• Documentation has been updated

[github-actions]

This PR has been automatically marked as stale because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 days of this comment.
If you're still working on this, please add a comment or push new commits.

[avinab-neogy]

@xrmx @carlosalberto Bumping this! It's out of draft and ready for a review. I went with 10_000 to match metrics, but just let me know if you'd rather I align it to 30000 for traces instead and I'll push an update.