Camel Debugger Improvements

* Hiram talked about being able to have multiple breakpoints active, eg so you can have a JMS with 10 concurrent consumers.  
  And have it suspend all 10 consumers, and you can choose which thread to debug and resume/step. 
  This would require code changes in camel-core. And also in Fuse Tooling to allow end users to choose mode (as today = suspend first or the new suspend all).

   --> that needs Camel changes first before I can work on that


* In the UI editor add tooltip with the performance details for the eips. We have them today in the processor mbean/view 
   where you can see: Total Exchanges, Min Time, Max Time, Average Time.

   --> Those values are available in the variables view under the variable "Processor". So I would say thats enough.


* Draw the connectors between the EIPs using a different color, with the path that the message was routed. eg today the arrows 
   is colored black. But if you could color them with green/blue etc for that path it has taken, then that would look cool in the UI when you 
   see that as part of step over / resume to next breakpoint. Especially when doing content based routing where the message can be
   routed through different paths.

   --> It is of course nice looking but you already have that information in the stackframes list in your current thread. Maybe 
        not worth the amount of time it would take to implement such a logic.


* You prefix the ids in the Camel XML with debugger (something). Maybe add that as postfix, or hide it, as when you do that, the labels in the UI changes, eg 
   before you have setBody(xxx) and when you set a breakpoint the label is: _debugger_id_setBody, and because the label gets cut, the 
   users cannot see the setBody anymore. And all breakpoints appears to have the same label.

and 

* About #9 you could probably do this under the covers, set those ids, and then save the file. And when you go back to edit the xml, then you can "detect 
   those automatic generated ids, and remove them". So the end users do not see that "warning message". As Camel end users do not very often use those 
   "id"s, so they may get confused what this is about.

   --> I am not a friend of doing hidden changes to users files. Implementing such a logic is error prone as in case of a program crash or similar it would leave 
        the user with a changed camel context file and he would for sure wonder why its changed and who changed it. So my suggestion is to simply remove 
        those ugly prefixes and only use what camel usually generates when a id is missing but still inform the user that we intend to do changes on his file.