Improve plugin options

[jesper-friis]

Description

Improve option handling for plugins. This PR tries:

• Remove the limits on possible option values you can pass to storage plugins, due to the restriction imposed by the allowed characters in the query part of an URL. This currently poses a strong limits what data you can pass as an option.
• Make it more convenient to pass options to plugins (transparent URL encoding).
• Allow option values to be any JSON-serialisable Python object.

Tasks:

• Implement URL-encoding/decoding in C
• Make URL-encoding/decoding accessele to Python
• Let dlite_option_parse() transparently URL-decode the option string
• Let Options Python class transparently URL-decode the option string
• Add Python API for creating an option string from a dict that transparently URL-encode the values
• Allow to provide options as dict to the high-level Python API, like Storage, and Instance.save(), ...

Type of change

• Bug fix & code cleanup
• New feature
• Documentation update
• Test update

Checklist for the reviewer

This checklist should be used as a help for the reviewer.

• Is the change limited to one issue?
• Does this PR close the issue?
• Is the code easy to read and understand?
• Do all new feature have an accompanying new test?
• Has the documentation been updated as necessary?

[francescalb]

Arguments? Instance Variables I suppose? And shouldn't this be in the docstring og the init?

[jesper-friis]

Yes, you are right, the arguments refer to the arguments passed to the __init__() method. But it is common to document arguments in the class docstring. I like to do it for the following reasons:

• In case the class has both a __new__() and a __init__() method, we don't need to duplicate the argument documentation if we keep it in the class docstring.
• The __new__() and __init__() methods starts with an underscore and may be hidden by some documentation systems.