core, jp: component handling + client handling refactoring:

- SàT can now handle components
    - plugin have now a "modes" key in PLUGIN_INFO where they declare if they can be used with clients and or components. They default to be client only.
    - components are really similar to clients, but with some changes in behaviour:
        * component has "entry point", which is a special plugin with a componentStart method, which is called just after component is connected
        * trigger end with a different suffixes (e.g. profileConnected vs profileConnectedComponent), so a plugin which manage both clients and components can have different workflow
        * for clients, only triggers of plugins handling client mode are launched
        * for components, only triggers of plugins needed in dependencies are launched. They all must handle component mode.
        * component have a sendHistory attribute (False by default) which can be set to True to allow saving sent messages into history
        * for convenience, "client" is still used in method even if it can now be a component
        * a new "component" boolean attribute tells if we have a component or a client
        * components have to add themselve Message protocol
        * roster and presence protocols are not added for components
        * component default port is 5347 (which is Prosody's default port)
    - asyncCreateProfile has been renamed for profileCreate, both to follow new naming convention and to prepare the transition to fully asynchronous bridge
    - createProfile has a new "component" attribute. When used to create a component, it must be set to a component entry point
    - jp: added --component argument to profile/create
    - disconnect bridge method is now asynchronous, this way frontends can know when disconnection is finished
    - new PI_* constants for PLUGIN_INFO values (not used everywhere yet)
    - client/component connection workflow has been moved to their classes instead of being a host methods
    - host.messageSend is now client.sendMessage, and former client.sendMessage is now client.sendMessageData.
    - identities are now handled in client.identities list, so it can be updated dynamically by plugins (in the future, frontends should be able to update them too through bridge)
    - profileConnecting* profileConnected* profileDisconnected* and getHandler now all use client instead of profile

src/plugins/plugin_misc_text_commands.py

@@ -60,7 +60,7 @@ class TextCommands(object):
         log.info(_("Text commands initialization"))
         self.host = host
         # this is internal command, so we set high priority
-        host.trigger.add("messageSend", self.messageSendTrigger, priority=1000000)
+        host.trigger.add("sendMessage", self.sendMessageTrigger, priority=1000000)
         self._commands = {}
         self._whois = []
         self.registerTextCommands(self)
@@ -168,12 +168,12 @@ class TextCommands(object):
         self._whois.append((priority, callback))
         self._whois.sort(key=lambda item: item[0], reverse=True)
 
-    def messageSendTrigger(self, client, mess_data, pre_xml_treatments, post_xml_treatments):
+    def sendMessageTrigger(self, client, mess_data, pre_xml_treatments, post_xml_treatments):
         """Install SendMessage command hook """
-        pre_xml_treatments.addCallback(self._messageSendCmdHook, client)
+        pre_xml_treatments.addCallback(self._sendMessageCmdHook, client)
         return True
 
-    def _messageSendCmdHook(self, mess_data, client):
+    def _sendMessageCmdHook(self, mess_data, client):
         """ Check text commands in message, and react consequently
 
         msg starting with / are potential command. If a command is found, it is executed, else and help message is sent
@@ -181,7 +181,7 @@ class TextCommands(object):
         commands can abord message sending (if they return anything evaluating to False), or continue it (if they return True), eventually after modifying the message
         an "unparsed" key is added to message, containing part of the message not yet parsed
         commands can be deferred or not
-        @param mess_data(dict): data comming from messageSend trigger
+        @param mess_data(dict): data comming from sendMessage trigger
         @param profile: %(doc_profile)s
         """
         try:
@@ -254,7 +254,7 @@ class TextCommands(object):
     def _contextValid(self, mess_data, cmd_data):
         """Tell if a command can be used in the given context
 
-        @param mess_data(dict): message data as given in messageSend trigger
+        @param mess_data(dict): message data as given in sendMessage trigger
         @param cmd_data(dict): command data as returned by self._parseDocString
         @return (bool): True if command can be used in this context
         """
@@ -290,7 +290,7 @@ class TextCommands(object):
         mess_data["type"] = C.MESS_TYPE_INFO
         mess_data["message"] = {'': message}
         mess_data["extra"]["info_type"] = info_type
-        self.host.messageSendToBridge(mess_data, client)
+        self.host.sendMessageToBridge(mess_data, client)
 
     def cmd_whois(self, client, mess_data):
         """show informations on entity