Refactor logs:default command to scheduler-logs

[josegonzalez]

Currently, the logs:default command calls the docker binary directly to retrieve application logs. This really belongs in the domain of the scheduler in use, as the docker binary may not always be used to run applications.

We should implement a scheduler-logs trigger, which would be called as follows:

# where `TAIL` and `PRETTY_PRINT` can be `true` or `false`
# `NUM` may be empty, meaning it has no specified value
plugin trigger scheduler-logs $DOKKU_SCHEDULER $APP $PROCESS_TYPE $TAIL $PRETTY_PRINT $NUM

A scheduler plugin may choose to implement the PRETTY_PRINT or NUM arguments, though should be able to:

• tail logs (or output a reasonable number of lines, up to the implementor to decide)
• fetch logs for all process types or just a single process type
• when fetching logs for multiple process types, it must prefix each line with a variable approximating $DYNO.

[josegonzalez]

Related is #2268, though a scheduler plugin may choose to ignore any and all log driver options for the purposes of retrieving logs.

[josegonzalez]

Closing as there is a pull request open.