Add blueprint extensions to get and register RPC services

Added several blueprint extension elements to support RPCs:

<rpc-implementation> - registers a global RPC implementation. If
"interface" isn't specified, it registers all RpcService interfaces
implemented by the ref'ed instance.

<routed-rpc-implementation> - registers a routed RPC implementation
and returns a RoutedRpcRegistration instance for injection into other
beans via the specified "id. If "interface" isn't specified, it looks
for a single RpcService interface implemented by the ref'ed instance.
If multiple are found it fails since only one RoutedRpcRegistration
instance can be returned.

<rpc-service> - finds the registered RpcService corresponding to the
specified "interface" and makes it available for injection into other
beans via the specified "id".

Internally the bean implementations obtain the binding
RpcServiceRegistry.

Change-Id: I432dfb5378ca8368e41fb5375c9d5515dd3e714d
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>

Add decorating "type" attr extension for service refs

Added an attribute extension to the <service> element that adds an
OSGi service property of the form "type=<value>". This allows providers
of a service to advertise the type of the service to distinguish it from
other services provided for the same interface.

Conversely, the extension can also be used in <reference> elements to allow
consumers of the service to specify which service implementation they
want.

As a convention, the "default" type should be used for the default
implementation of the service with other types being specialized
implementations. This allows consumers to obtain whichever
implementation the provider deems as the default without having to
explicitly know it and allows the provider to switch to a new
implementation without requiring all consumers to change their
referenced type.

If a consumer doesn't specify the "type" attribute, it may be ambiguous
as to which service is obtained. Rather than requiring that the "type"
attribute be specfied for every <reference> element, I added an attribute
extension attribute, "use-default-for-reference-types", to the <blueprint>
element that automatically adds a filter to all <reference> elements where
the "type" property is either not set or set to "default" if the "type"
attribute isn't explicitly specified. This ensures the default implementation
is imported if there are other implementations advertised with other types.

Change-Id: Ie61bb45da1c7539732cd31ab0f8130233c9696fc
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>

Add restart-dependents-on-update blueprint extension

Added an attribute extension to the <blueprint> element that adds a bean
processor that scans for any "property-placeholder" elements and reacts to
changes to the corresponding cfg file by restarting this blueprint
container and any dependent containers that consume OSGi services provided by
this container in an atomic and orderly manner. This mimics the module
restart functionality provided by the CSS.

A new OSGi service, BlueprintContainerRestartService, was added that
performs the orderly restart. This service is created and registered by
the BlueprintBundleTracker.

Change-Id: I5f463303c3a8aba35b3ed914268bdc67ac795a5a
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>

Add Blueprint bundle tracker

Added an initial blueprint bundle and BlueprintBundleTracker which
scans ACTIVE bundles for blueprint XML files located under the well-known
org/opendaylight/blueprint/ path and deploys the XML files via the
Aries BlueprintExtenderService. This path differs from the standard
OSGI-INF/blueprint path to allow for controlled deployment of
blueprint containers in an orderly manner.

Change-Id: I21fd5aeb1d9ccd609caa8ea89bd66648fee5ad97
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>