environment lockfile parsing & usage in create and install sub-commands

[Klaim]

Adds the handling of environment lockfile (*-lock.yaml files) specifying specific dependency versions (see conda lock) when using the subcommands create and install.

[Klaim]

There is one test (or set of tests) missing that I'm working on, but it could be added after.

[JohanMabille]

I added a "m_data" member of type any to mamba_error so that you can store additional information without having to subclass it. Do you think it would make sense to use it to store the parsing error code?

[Klaim]

I used it to store the YAMLcpp error type_index, but I could store the code there too. This would mean storing a struct instead then.

[Klaim]

I pushed the change, also improved the interface. Storing extra data using this technique with inheriting error types seems to work well.

[Klaim]

After discussion with Johan I will remove the additional error type and move it's data into our mamba_error type. Wait for it before merging ^^

[Klaim]

@JohanMabille I did the changes we talked about regarding error handling, is it fine this way?

[JohanMabille]

Yes, that's perfect!

[JohanMabille]

@wolfv I think this one can be merged.

[Klaim]

Agreed. I will put the tests in another PR once I fix the issue that this PR introduces with --json (basically it seems the json output is malformed but only with lockfiles, I see why but didn´t find a good solution yet). That issues prevents me from doing the checks in the tests.

[Klaim]

The issue preventing me to add tests here is fixed (#1600) so I added the tests here.

[wolfv]

Wouldn't this throw a YAML Exception if no version is available? Just wondering if we should catch the exception and transform to an expected?

[Klaim]

So far for any Yamlcpp exception, I assumed it's fine to catch it in read_environment_lockfile (below) instead of every functions, but I could catch them earlier and return expected indeed. In read_environment_lockfile the exception is already converted to an expected, though it's not visible from here so no problem if you prefer local catching instead.