[light-client] Create light-client testing infrastructure

[lexnv]

Reutilize as many subxt tests as possible while ensuring the light-client properly functions.

• modify/adjust the substrate-runner to spawn local substrate nodes compatible with the light client
  (light-client waits indefinitely for the GranPa warp sync while spawning a single node)
• guard the tests that are compatible with light-client (light-client exposes a subset of the RPC methods exposed by substrate) with a feature flag
• add a CI step to run the subxt tests using a light-client

[lexnv]

• Testing support has been added in light-client: Add experimental light-client support #965
• substrate runner is capable depending on the unstable-light-client feature flag to use light-client
• a subset of tests are running in the CI targeting the polkadot live chain
• Add light client platform WASM compatible  #1026 extends the testing infrastructure for WASM purposes

For the experimental light-client support those offer great coverage and give us enough confidence.

Stabilizing the light client

Ideally, when stabilizing the light client we can take it one step further and reuse all the tests from the subxt's repo for both the jsonrpsee client and for the light-client as well. Currently, the smoldot syncs up slowly with a freshly booted substrate node on x86 (tested both on CI and local AMD box).
The syncing speed has been noted also on live chains by our CI: #1065

It may be possible to overcome the need of spawning a dedicated substrate node that is shared for all tests.
That will allow smoldot to sync only once, but will break some tests expectations.
For more details about this see:

subxt/testing/integration-tests/src/light_client/mod.rs

Lines 7 to 27 in 84df959

	//! The initialization process of the light client can be slow, especially when
	//! it needs to synchronize with a local running node for each individual
	//! #[tokio::test] in subxt. To optimize this process, a subset of tests is
	//! exposed to ensure the light client remains functional over time. Currently,
	//! these tests are placed under an unstable feature flag.
	//!
	//! Ideally, we would place the light client initialization in a shared static
	//! using `OnceCell`. However, during the initialization, tokio::spawn is used
	//! to multiplex between subxt requests and node responses. The #[tokio::test]
	//! macro internally creates a new Runtime for each individual test. This means
	//! that only the first test, which spawns the substrate binary and synchronizes
	//! the light client, would have access to the background task. The cleanup process
	//! would destroy the spawned background task, preventing subsequent tests from
	//! accessing it.
	//!
	//! To address this issue, we can consider creating a slim proc-macro that
	//! transforms the #[tokio::test] into a plain #[test] and runs all the tests
	//! on a shared tokio runtime. This approach would allow multiple tests to share
	//! the same background task, ensuring consistent access to the light client.
	//!
	//! For more context see: https://github.com/tokio-rs/tokio/issues/2374.