Because `polkadot-sdk` depends on `zombienet-sdk`, outdated dependencies
will slow its compilation.
This PR align dependencies with `polkadot-sdk`

Fix race condition (overriding files in fileserver).

Fix `fn nodes()` visibility (#277)

fix #274 

refactor trait and fix `nodes()` visibility.

- Fixes
  - #275

fix for https://github.com/paritytech/polkadot-sdk/issues/6575

cc: @iulianbarbu

- Added
   - ChainUpgrade trait, implemented for both relay and parachain.
 
- Add example of parachain upgrade.

cc @ordian

Fix:
 - Grandpa keys injected. #267
 
Added:
 - Name validation (for nodes) #266
 - Improve dx (@ozgunozerk ) #261

Fix #250, follow same _impl_ of `v1`

Revamped version of #252, didn't overwrite that PR in case you guys want
to compare both solutions.

Fixes #251 


TL;DR -> here is the suggestion:
```rust
let network_config = NetworkConfigBuilder::with_nodes_and_chain(
    vec!["alice".to_string(), "bob".to_string()],
    "rococo-local",
)
.with_collators_and_parachain_id(vec!["collator1".to_string(), "collator2".to_string()], 100)
.build()
.unwrap();
```

I found an even better way than creating a wrapper. Here is the summary:

- I want to protect the safety measures provided by the original crate
as we discussed.
- At the same time, I don't want to opt-out of the high-degree of
configurability that `configuration` crate offers. Even though the aim
is to grant better DevX to the community, it should still preserve the
configuration options.
- “advanced users can still use the `configuration` crate if they wanted
to” is not a good argument imo. Here is the reason:
- although there are many common settings amongst the projects in the
ecosystem, probably most of the projects only tinkers with a specific
setting w.r.t their needs, and this specific setting is most likely
changing across projects. So, if we do not expose the tinkering options
to people with this wrapper approach, most of the projects won’t use
this wrapper. Then what is the point?
- The aim should be providing the default options with a better DevX,
whilst still providing a way to configure niche details somehow within
the same API.
- As first trial, I completed simple to use wrapper builders with the
default settings. However, to expose the niche configurations, I had to
copy-paste nearly every other function/method in the `configuration`
crate.
- And also, in order to comply with the `configuration` crate’s type
state pattern, I had to export nearly all the states from
`configuration` crate for the builder types in the `lib.rs`. The whole
thing was quickly becoming ugly.
- The difference between my wrapper and the `configuration` crate was,
basically the extra methods that granted better DevX (for initializing
the structs with default settings).
- So I thought, instead of creating a new wrapper with tremendous amount
of duplications, I can simply put these new methods into the
`configuration` crate itself!

Notes:

- there are 2 new methods: (edited after last commit)
    - `with_nodes_and_chain`
    - `with_collators_and_parachain_id`
- I also expanded the tests for these new methods.
- I want to signal to the developers that these new methods are easier
and faster to use compared to their equivalents, since they are
utilizing the default settings, and should be much less intimidating to
newcomers
- So, I tried to name the methods accordingly, but they turned out to be
a bit long. Don't know whether we can do better, I'm open to all
suggestions.

Hope it makes sense!

Add: 
  - Validate `node_name`, can't be empty

cc: @ozgunozerk

Fix
 - CI using native provider

- Fixes
  - Upgrade heleper for CI.

Added
 - Runtime upgrade helper for relaychain.

Added:
  - Helper to perform a runtime upgrade on the relaychain
 
```rust
    let wasm = "file_path__or__url_to_*.compact.compressed.wasm";
    network
        .relaychain()
        .runtime_upgrade(RuntimeUpgradeOptions::new(wasm.into()))
        .await?;
```

- Fixes: 
  - Use correct stash account
  -  Support single collator in `toml` (load from file)
  
- Added
- Add support for `evm` parachains, through the `evm_based` config (both
in load from toml and builder).

- Fix stash derivation (use `//`)
- Add `evm` support, you can set your parachain as evm based with
`evm_based(choice: bool)`.


Fix: #247 
cc: @AlexD10S / @al3mart

`v1` version support define a parachain with a single collator using
`[parachain.collator]` (note this is a map and not a sequence). But in
the `sdk` we drop support in favor of always use a vec<NodeConfig>. This
pr allow to use the old toml definition __only__ with the load_from_toml
method.

cc:  @AlexD10S

This is nothing big  :) 

The code execution logic is already present under `pjs` function, yet it
is duplicated for `pjs_file` function.

This change re-uses the existing code, so that you won't have to change
it twice in the future.

Co-authored-by: Javier Viola <[email protected]>

- Fixes:
  - `wait` metrics
  - `validation` for binaries (native provider).

Fixes:
- `wait` methods for metrics
- `path` checking for `native` provider validation.

- Small refactor and fixes.

- Add binaries verification to
`validate_spec_with_provider_capabilities`
- Improve error display in providers.

When testing `zombienet-sdk` with cross-chain calls with Asset Hub, we
found that the hrmp channels passed to the chainspec caused the
following issue:

`Error: "Invalid JSON blob: invalid type: map, expected a tuple of size
4 at line 1 column 2794"`

This is because the values of `HrmpChannelConfig` serialise to a map
instead of a tuple, as expected by
https://github.com/paritytech/polkadot-sdk/blob/fc906d5d0fb7796ef54ba670101cf37b0aad6794/polkadot/runtime/parachains/src/hrmp.rs#L492.
Tests were updated accordingly to facilitate this fix.

Additional commits were also added to enable some of Asset Hub on
Polkadot functionality observed in the classic Zombienet repo, so that
we are able to launch a local Polkadot network with Asset Hub should
anyone require. Example configuration files can be found at the bottom
of https://github.com/r0gue-io/pop-cli/pull/278/files for anyone
interested, although that PR is still a work in progress and dependent
on this one being accepted.

PS - I added tests where I could, but additional tests might require
some minor refactoring to make it easier to test only the logic that is
changed by this PR, which I am not sure what the appetite is? An example
would be refactoring the file name generation in `keystore.rs` into its
own function to more easily test the outputs without the `scoped_fs`.

WIP

---------

Co-authored-by: Javier Viola <[email protected]>