PROACTIVE-1222  AMQP: use single exchange for RPC
PROACTIVE-1221  AMQP: need to better manage AMQP Connections and
Channels
PROACTIVE-1223 AMQP: if remote object dies then call to this objects
hangs forever

Following changes are done in this commit:

- modified code to use single exchange for remote calls: now factory
creates two global exchanges: 'fanout' which is used to discover
objects, and 'direct' for remote calls. When AMQPRemoteObjectServer is
created it binds its queue to the both exchanges, for 'direct' exchange
queue name is used as routing key. AMQPRemoteObject don't need to create
temporary exchange, it sends message to the global 'direct' exchange
using queue name is used as routing key.

- cached Connections can't stored in the WeakHashMap<String,
Connection>, since when string key is collected after GC then Connection
is removed from map, but remains opened. I changed it to use regular
HashMap  (and I guess in most cases there will be only one AMQP server,
so only one Connection will be created per JVM) 

- opening new channel and creation of new temporary reply queue for each
remote call has significant performance impact,
to optimize it caching for channels was implemented. 

For each unique AMQP broker URL ConnectionAndChannelFactory creates
instance of CachedConnection which holds AMQP Connection and set of
cached Channels. Now all operations working with AMQP Channels are
executed using following steps: 
- get ReusableChannel instance using AMQPUtils.getChannel
- execute operation using AMQP Channel provided by ReusableChannel
- after operation completes successfully channel is returned to the
cache using AMQPUtils.returnChannel
- if some error happens during operation execution then it is supposed
that channel can't be reused, it is closed and isn't returned to the
cache 
Note: there are two types of cached channels: RpcReusableChannel - used
to execute remote calls (it holds temporary reply queue which is reused
for multiple remote calls), ReusableChannel is used in all others cases
when temporary reply queue isn't needed. 

- to fix PROACTIVE-1223 following logic is used to execute remote call:
now AMQPRemoteObject doesn't wait forever for reply, but periodically
checks that target remote object's queue still exists (for this check
special AMQP method 'queueDeclarePassive' is used).
   
Change-Id: I2bd74a67937d684f1e9b836ce9d43306ccd7b38f
Update .classpath.
PROACTIVE-788 : In component API tutorial (parts 3.3.3 and 3.3.4),
subcomponents are not added into the composite component.
Fix for part 3.3.4.
Merge branch 'master' of git@gitorious.ow2.org:ow2-proactive/programming.git
PROACTIVE-1222  AMQP: use single exchange for RPC
PROACTIVE-1221  AMQP: need to better manage AMQP Connections and
Channels
PROACTIVE-1223 AMQP: if remote object dies then call to this objects
hangs forever

Minor modifications:
- rpc timeout was moved to the AMQPConfig
- increased timeout for the newCachedThreadPool in
AMQPRemoteObjectServer
PROACTIVE-1178 AbstractUniversalBody uses UniqueID.toString() to
generate unique active object name

Problem:
UniqueID.toString() is used to generate unique objects names, but if
debug logging is enabled for proactive core than there is no guarantee
that it generates unique id.

Fix:
I think to generate unique names code should use
'UniqueID.getCanonString()', but now 'UniqueID.toString()' is used in
too many places and it can be dangerous to change this. So as safe fix I
changed UniqueID.toString() to always return getCanonString().
PROACTIVE-1227 - Support user name, password and vhost in the AMQP
configuration

Added in the AMQPConfig properties which allow to set username, password
and vhost. Changed AMQPUtils and ConnectionAndChannelFactory to use
these parameters.