chore: Create FDv1 datasystem implementation

[jsonbailey]

Note

Adds Impl::DataSystem::FDv1 to wrap v1 data flow, extracts Impl::DataSource::NullUpdateProcessor, updates DataSystem interface, and adjusts client and tests accordingly.

• Core / Data System:
  • Add LaunchDarkly::Impl::DataSystem::FDv1 (lib/ldclient-rb/impl/data_system/fdv1.rb) wiring v1 data source/store via broadcasters, status providers, and UpdateSink; implements start/stop, store, data_source_status_provider, data_store_status_provider, flag_change_broadcaster, data_availability, target_availability, and processor selection (stream/poll/null/custom), passing diagnostics to streaming.
  • Update DataSystem interface (lib/ldclient-rb/impl/data_system.rb): start now returns a Concurrent::Event (no arg), add flag_change_broadcaster, set_diagnostic_accumulator, expand DataAvailability, and add diagnostic/initializer/synchronizer mixins and Update class.
• Data Source:
  • Extract NullUpdateProcessor to lib/ldclient-rb/impl/data_source/null_processor.rb and update references; remove old inline class from ldclient.rb.
• Client:
  • Use namespaced NullUpdateProcessor and require new file in lib/ldclient-rb/ldclient.rb.
• Tests:
  • Add specs for NullUpdateProcessor and FDv1; update DataSystem contract specs; extend test helpers (spec/mock_components.rb).

^{Written by Cursor Bugbot for commit 45e8c70. This will update automatically on new commits. Configure here.}

[jsonbailey]

I was a little torn on having the ready_event passed in vs returning it. The existing data_source public interface for its start method returns a Concurrent::Event. This means we would either need an interface layer to sync the two events between the data system and the data source, or we would need a breaking change to have the data source interface accept the event vs return it.