Changes to user requested task kills in custom executor

[ssalinas]

Two main changes in this:

• For any user-requested kill (direct task kill, task destroy, also includes bounce at the moment), send a framework message to the executor to trigger the kill (if using a custom executor)
• In the SingularityExecutor, don't skip to destroy if we receive a kill (framework message or normal) and there is already a kill process running

In the case when sending the framework message, I am still sending the normal kill as well (now that the executor handles it properly). This is so any other executors (default mesos or another custom) will still receive the kills they expect. I couldn't think of a better way around this since we do not have an easy way to determine that the executor is custom AND is a singularity custom executor, suggestions welcome for easier compatibility with other executors.

@wsorenson @tpetr

[wsorenson]

I think we should only send the task destroy as a message.

[ssalinas]

That makes sense. I'll keep it as regular kills for any other cases then

[ssalinas]

Updated to only use the framework message on a user initiated task destroy (which is now it's own task cleanup type to help differentiate it). Going to work with the task kill endpoint a bit more to make it clearer when a destroy will happen. Realized we can probably get it a bit cleaner than just using the override query param

[ssalinas]

This has been doing well since the fix in #1141 , merging