Support camelCase for parachain chain spec

[xlc]

Firstly the chain spec parsing should not deny_unknown_fields. Parachain may want to have custom fields for whatever reason and it will be poor compatibility to reject them.

Secondly I don't know why cumulus itself is mixing both camelCase and default snake_case in chain spec, but at Acala we are all using camelCase, and it is incompatible to smoldot currently. It will be good if both cases can be handled.

[tomaka]

Sorry but I'm in favor of well-defined formats, and against having to make approximate guesses.
Denying unknown fields is a guarantee that smoldot doesn't exhibit for example consensus-related issues because it didn't recognize an important field in the chain spec.

The objective of a chain spec document is to describe a chain that the client doesn't know about. It's similar to a configuration file destined to the client. I feel like it kind of kills the point if each chain has their own tweaks to the format of their spec.

Assuming that your chain spec doesn't change, it's a one off effort to manually change the fields to make it work with smoldot, which I think is acceptable?

[tomaka]

That being said, if the problem is just with para_id and relay_chain, I'm fine with accepting their camelCase version as well.

I just want the smoldot chain specs to be well-defined, and their differences with cumulus chain specs to be clear and trackable.

[xlc]

Ok. We don't plan to customize our chain spec so that's fine.

We do want to use camelCase for the sake of consistency. It is cumulus issue using inconsistent case here.