Adress last OSGi merge comments

Mea culpa - this is what I expected to see.  Jet lag must have been playing tricks with my eyes.

However I'd really like to be able to drop `java:`.

I thought from IRC (after dev list discussion) @richardcloudsoft was weakly in favour of this -- optimizing YAML / user experience.  A few reasons for this:

1) the 'java:` is an ugly weird prefix -- and so I'd rather avoid it except where really needed for disambiguation.  if we had a more elegant mode-of-type specification technique (and this might come in time) then I'd be more sympathetic to the "always be explicit" idea.

2) the common case of java class being added to catalog becomes much more concise if we add this special interpretation, viz: without it, a user must define

    brooklyn.catalog:
      id: <type>
    services:
    - type: java:<type>

whereas if we had the simple rule that "where a cataog item with a given type/id references a service type of the same name, it is interpreted as a java class" a user could (since we default to service type name as the catalog item id) simply submit:

    services:
    - type: <type>
    
3) it feels safe here because there is no chance that we misconstrue the user's intention; they certainly aren't intending a circular reference.  all we are doing is, instead of giving a runtime error, we are doing what almost certainly they intended.  the biggest risk is that we have allowed some behaviour which we end up wanting to deprecate (if we require being explicit) but i think in time we might have better ways to be explicit and so there is also a fair chance `java:` will be deprecated.  and i expect a better chance it will be nice to keep the smarts for this common case of using the same catalog ID as java type name.