BUG: make get_cosmology constistent with set_cosmology

[mj-will]

As it stands, get_cosmology does not support the same inputs as set_cosmology despite what the doc-string implies.

This PR moves the logic from set_cosmology to get_cosmology. The former now just calls the latter rather than having duplicate logic.

[mj-will]

I don't think the change I've made to support braces ({...}) is particularly robust, since something like {'a': (1, 2)} won't work, I think. I'll try to think of a better way of doing this but I'm open to suggestions.

[ColmTalbot]

I don't think the change I've made to support braces ({...}) is particularly robust, since something like {'a': (1, 2)} won't work, I think. I'll try to think of a better way of doing this but I'm open to suggestions.

Yeah, it won't work with nested cases. I don't think there is much point trying to go much deeper with string parsing. I'm happy to get this in, but I would vote to document better that for complex cases, the json version is much more robust.

[ColmTalbot]

I think this is good in general, and probably a safe change. I'm trying to figure out if there are any currently valid prior specifications that will behave differently after this change?

...(..., foo={a: 1}, ...)

Returns the same value as before with this change. I can't think of any other versions that might have changed at this stage. Maybe if there is a single { in an argument.

This has also solved a longer-running issue with latex labels, e.g.,

...(..., latex_label="H_{0, 1}", ...)

The following still fails, but it feels a bit contrived.

...(..., latex_label="H^{0, 2}_{0, 1}", ...)

[mj-will]

@ColmTalbot what do you think about getting this into 2.4.0?

[ColmTalbot]

Yeah, I think we should get a version of this in.