Make Picard search box smart enough to detect mbids.

If a release mbid is given (search type = Album) it will try to load it as
when using web browser tagger link.

If string looks like a known entity (artist, release-group, label, track)
it will open browser on corresponding url.

Examples:
Select box on Album + "abb7caf1-ac93-48e1-a066-60caad07e1a7" -> load release (http://musicbrainz.org/release/abb7caf1-ac93-48e1-a066-60caad07e1a7)

Select box on anything + "http://musicbrainz.org/artist/c19ff12b-058f-44a8-b245-b0efb4752925" -> open browser on Artist page
"ARTIST := c19ff12b-058f-44a8-b245-b0efb4752925 !!" -> open Artist page
Complete the list of known entities.
Better metadata box locking

The previous use of "selection_mutex" didn't really prevent race conditions.
The only thing really stopping them was the hackish "throttling" implemented
using self.updating and self.update_pending. If self.update was called while
another update was already in-progress, it'd set self.update_pending to True
and return, thereby reducing the chance that two update threads would execute
simultaneously.

Another thing to note is that race conditions here are almost impossible to
reproduce in CPython by default, because the interpreter only checks for
possible thread switches every 100 virtual instructions or so (configurable
using sys.setcheckinterval). Still, relying on such behavior bothers me.

The new attempt here reduces the need for locking considerably, because
instead of having a constant, shared self.tag_diff object, each update
thread creates its own and passes it on as the result.

So, selection_mutex is now simply used to protect the cached selection vars
while they're being set in _update_selection and read in _update_tags. As
mentioned, CPython's default behavior makes selection_mutex pretty much
unnecessary, but I don't think it adds much overhead given its limited use.

Tested on Mac and Windows.
Fix performed vocals attribute with no vocal type set

This fixes a regression since e16b2533c where picard no saves vocal ARs
with no type set as generic "performer" ars; appearing in the UI like
    Performer []: Some Vocalist
    Performer [guest]: Some Guest Vocalist

Add special handling for the vocal relationship type to use a fallback
string if there is no vocal type set. The fallback string is "vocals"
(earlier versions of picard used "vocal"), for consistancy with the
current vocal type strings, which look like "lead vocals", "background
vocals", etc.
Merge pull request #119 from zas/searchmbid

Make Picard search box smart enough to detect mbids.
Merge pull request #128 from kepstin/vocals-rel-fix

Fix performed vocals relationship with no vocal type set