Clean up command line flags

[fhenneke]

We currently support lots of command line flags. Some of them are a bit redundant (see this comment on --post-tx and --dry-run). Some have an overlap with configuration parameters (--ignore-slippage vs config.buffer_accounting_config.include_slippage). After merging #492 we have another one (--send-to-slack).

Cleaning up the those flags and simplifying the logic where they are used would be useful.

[fhenneke]

More context on flags for output of the script:

Without this PR, we have the flags --post-tx and --dry-run.

• Independent of those flags, transfers (and overdrafts) for payouts are computed.
• The --post-tx flag triggers a code path where auto_propose is called. That function requires the signing key as it actually sets up a signed transaction. If the --dry-run flag is not set, additionally slack credentials are required. A message is sent to slack and the transaction is posted to a safe. If --dry-run is set, no message is sent nor is the transaction posted.
• Without the --post-tx flag, another code path is triggered. It does contain the manual_propose function. The --dry-run flag now does not have any effect. The manual propose function does not require a signing key nor slack credentials. Instead, a csv is created. It can be used to manually propose a transaction via the safe ui.
• The auto_propose function additionally adds an unwrap, which can fail if funds are missing. This sometimes requires to run the script twice, once without a flag (to check transfers) and once with flags --post-tx --dry-run to check if the creation of the transaction fails.

With this PR, there is an additional --send-to-slack flag.

• If --post-tx is set, the additional flag has no impact.
• If --post-tx is not set, a code path with the function manual_propose is taken. This function now also sometimes requires slack credentials. Which leads to some overlap between manual_propose and auto_propose.

A more appropriate set of flags might be:

• --create-csv (which switches on the output of a csv)
• --create-tx (which would behave like --post-tx --dry-run)
• --post-to-safe (which requires --create-tx and would behave like --post-tx)
• --post-to-slack (which would behave like --send-to-slack in case --post-tx is not set, and like --post-tx currently does otherwise)

The code would then have a function for each of these cases. Those functions would be called from some other function which implements appropriate if flag: do_stuff logic. Being able to switch on a csv output independently of the creation of a transaction will make testing changes easier.