Update _hosting_task_log_class() to match drush _drush_print_log()

This has made the entire log grey for me.

fyi, these are all the task types I see:

mysql> select distinct type from hosting_task_log;
+------------+
| type       |
+------------+
| backup     |
| bootstrap  |
| command    |
| debug      |
| error      |
| failed     |
| info       |
| memory     |
| message    |
| notice     |
| ok         |
| queue      |
| rollback   |
| status     |
| success    |
| successful |
| warning    |
+------------+
17 rows in set (0.00 sec)

Oddly, all the rows are getting a class of 'hosting-info', but I don't see why...

Sorry, almost everything was set to 'hosting-info'. I think 'message' should remain a 'hosting-success', no?

Revised patch for #5 attached.

If we go with what's in _drush_print_log(), then we should probably change all instances of drush_log(..., 'message') to drush_log(..., 'success'), or something.

Fixed in Provision with d5a8862, and Hosting with 72f7db1.

As per #5, I switched to using 'success' rather than 'message' in Provision. This change means that 'status-info' is the default, so, for example, memory rows are no longer green. However, this better highlights the operations that are actually successful, and reduces the noise.

I think we could still tweak these a bit. For example, I think 'rollback' messages could be flagged as hosting-warning, and maybe 'debug' too.

Oops, I'd missed a push from Provision. I also cleaned up the rest, as per your suggestions.

Great!

I think having rollbacks as warnings is a great idea, although they will probably always end up in red because a rollback usually happens after an error, which should be red. Debug should be inconspicuous.

oups, didn't mean to change status.

ok, I made rollbacks orange, even though the overall task will remain red.

Fixed in 7e31ccc