…tion

If the key contains a dot sign, it is a repository option.
Improved detection -> ignoring dots after equals sign.

On the other hand, value_patter is supported only for repository options.

Parsed pattern: <repoid_pattern>.<option_name>[=<value_pattern>]

Bump version to 1.1.1

Option "mode" defines communication model between actions plugin and process.
Introduces 2 modes of communication: "plain" and "json".

"mode=plain" - Original and default communication model.
Parameters are passed to the process only by arguments when it starts.
Arguments may contain variables that are substituted before the process is
started. A process can modify libdnf5 settings (main configuration, repository
configuration, variables) and plugin actions variables by writing to standard
output.
Output line format:
- tmp.<actions_plugin_variable_name>=<value> - sets the value of action plugins
    variable <actions_plugin_variable_name>
- tmp.<actions_plugin_variable_name> - removes the action plugins variable if
    it exists
- conf.<option_name>=<value> - sets the value of option <option_name> in
    the base configuration
- conf.<repoid_pattern>.<option_name>=<value> -  sets the value of option
    <option_name> in the matching repositories
- var.<variable_name>=<value> - sets value of the variable <variable_name>

"mode=json" - Newly introduced communication model.
Parameters can be passed to the process before it starts using arguments just
like in "plain" mode. This mode adds bidirectional communication between
the actions plugin and the process. This is request/response communication.
The process sends requests and the actions plugin sends responses. The process
writes requests to the standard output and reads responses from the standard
input. The communication will be implemented later and will use JSON format.
This is a preliminary commit.

Processes send requests and the actions plugin responds.

- Request format:
{"op":"<operation>", "domain":"<domain>", "args":{<op_domain_spec_args>}}

"domain" is ignored in the case of the "log" operation.

- Response format:
{"op": "reply", "requested_op":"<op_from_request>", "domain":
"<domain_from_request>", "status": "OK", "return":{<data>}}

{"op": "reply", "requested_op":"<op_from_request>", "domain":
"<domain_from_request>", "status": "ERROR", "message":"<error message>"}

"return" is not included in the response to a request for a "log"
operation.

If the JSON request is unparsable - a syntax error or incomplete message,
or the response cannot be written, the action plugin closes both communication
pipes. The process must terminate if the communication pipes are closed.

If an error occurs while processing a request from a process,
the location of the hook definition is added to the log message.
e.g. `Syntax error from hook in file "{}" on line {}:`

For example, the "get" operation for "trans_packages" is only allowed
for the "pre_transaction" and "post_transaction" hooks.

To ensure the release of resources after an exception.