feat: reuse existing chain spec

[Daanvdplas]

Allow to provide an existing chain spec file for the chain flag. I aimed for flexibility and a clear flow in the code so that it is easily adaptable for future requirements.

Added an additional BuildSpec struct to separate the flow between getting the users input and secondary input (prompts), and generating the files with the provided options. This also allowed to not have to worry about the Option fields in the BuildSpecCmd which complicated the code.

If the user provides a chain spec file and it does not want to make changes to it (user is prompted whether it wants this), and e.g. the para id is not present in the file, a default value is used. No warning has been added as the chance of this happening is very small. Either due to a user mistake by manually removing it or a chain spec file is provided that is created without the pop cli which could cause to have no para id present. There will always be a para id in a chain spec file if it is created with the pop cli. This example counts for all the other Option fields in the BuildSpecCmd.

No tests have been written yet due to time and can be done if required

The build profile will be added as a separate PR after this is merged.

[AlexD10S]

Nice work! This definitely improves the DevEx.

The integration test is currently failing, see my comment for a way to test it without waiting for the full test to finish. Additionally, cargo test --doc needs to be fixed too after your changes.

The rest are minor comments to address and a few suggestions for improvement.

[al3mart]

Love the flow, and it's great having the possibility of creating and modifying existing specs!

There's a few nits that need revisiting, but it's looking great!

[al3mart]

@Daanvdplas thanks for the addressing the feedback! This is great!

I yet have a comment on fix: prepare_output_path.

I believe we are deviating on how we treat the input provided in --output
Given that we are telling the users:

  -o, --output <OUTPUT_FILE>       File name for the resulting spec. If a path is given, the necessary directories will be created

Whatever the user inputs should be the name of the file, I don't think we only need to consider the input as a file if it has the .json extension.
We already take the opinion of appending .json and -raw.json to the specs. But I guess we should respect the naming users provide

[Daanvdplas]

Imo it is a simple rule to follow, end your preferred name with .json, it makes the code easy as well. @AlexD10S wdyt?

[al3mart]

LGTM!

[AlexD10S]

Nice to see the unit tests in thepop-clicrate.

Just one little point before merge it. If I run cargo +nightly clippy I see a couple of warnings that can be fixed, or the CI will complain when point to main.