Feature Request: A congruent settings interface

[appetrosyan]

Right now there are no reasons why the settings file couldn't be a dictionary, so we can either extend the functionality of the settings file, or phase it out and move the logic into the function that actually uses it.

**Proposal 1: **
Add functions that load the settings file from other formats, allow serialising and de-serialising in a consistent manner, as well as adding the option to add the prior quantile or the log-likelihood at the stage of creating the settings object.

Pros:

• More functionality -- we only add new features.
• If using proper OOP, should either make settings immutable, or provide proper setters that run whenever the functions are updated, rather than only once.
• We could also test if the prior quantile / likelihood misbehave, early: could see if they accept an nDims long vector + return a tuple where necessary. Effectively, we prevent the end user from spending too much time debugging.

Cons:
It's bloat.

Proposal 2:
Remove the settings object entirely. Instead, provide all the validation as part of keyword arguments of the run_polychord method. The settings object essentially reduces to a dictionary.

Pros:

• Simpler procedural interface.
• No state to worry about and minimal runs remain minimal.
• Much easier to document.
• No chance of providing incongruent configuration to run_polychord() and settings.
• Can do without breaking backwards compatibility, by simply allowing all elements of the settings object to be passed to run_polychord().
• Can gradually phase out use of PolyChordSettings via (https://pypi.org/project/Deprecated/)

Cons:
Duplicated error checking. More code in the run_polychord() function.