Modify ModuleInfoBundleTracker to track RESOLVED bundles (round 2)

Modify ModuleInfoBundleTracker to track RESOLVED bundles (round 2)

My first patch https://git.opendaylight.org/gerrit/#/c/27138/ didn't
do well with the feature tests due the BundleContext bust wait so it
was reverted.

I went back to my original solution to confgure the ModuleInfoBundleTracker
to track RESOLVED and ModuleFactoryBundleTracker to track ACTIVE.
Originally when I tried that I had some failure due to the ModuleFactory
not loaded yet but I don't remember exactly what. This patch seems to work
fine - I've restarted karaf several times and also ran the tsdr features tests
several times successfully. Originally I did the first patch in stable/lithium
so maybe something else has changed in master or the way I did it wasn't right.

Since the initial yang module info's are now processed synchronously when the
BundleTracker is opened, I modified the ModuleInfoBundleTracker to
ensure it doesn't propagate runtime ex's. This would disrupt the
BundleTracker and the ConfigManagerActivator - if one module had an
issue the config manager wouldn't start.

For every YangModuleInfo scraped, it registers it with the
ModuleInfoRegistry. The backing impl is RefreshingSCPModuleInfoRegistry
which causes a new SchemaContext to be created from the current yang
models (via updateService). This isn't efficient - on startup, we'll get all
YangModuleInfo's in quick succession so, optimially, it should build the
SchemaContext once after open is complete. This is what the
GlobalBundleScanningSchemaServiceImpl does.

To accomplish this, I removed the call to updateService from
RefreshingSCPModuleInfoRegistry#registerModuleInfo - it is now
specifically called by ModuleInfoBundleTracker. This means the
ModuleInfoBundleTracker now references RefreshingSCPModuleInfoRegistry
instead of the ModuleInfoRegistry interface which makes it less clean.
Any other way would require changes to the ModuleInfoRegistry interface,
which I didn't want to do, or extending the interface which I didn't think that
was worth the effort. The RefreshingSCPModuleInfoRegistry is only used by
ModuleInfoBundleTracker.

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