Add track metadata plugin priority processing

All track metadata processors are equal but some are more equal than
others.

This commit allows a track metadata plugin to register with high
priority, and to run before plugins which are not high priority. This is
needed for the Standardize Performers plugin.
Add Standardise Performers plugin
Add NEWS
Add weight parameter to metadata_processors

Processors having more weight will be run first, default weight is 0.
Set default weights to 50 ...

... so we can have plugins with lower than default priority.
Set default weights to 100...

and plugin weight to 200.
Add PluginPriority and PluginFunctions classes

PluginPriority defines few common values for plugin execution priority.

PluginFunctions wraps ExtensionPoint and use defaultdict() to handle priorities.
It also provide a register() and a run() methods.
Use PluginFunctions and PluginPriority to reduce code redundancy.

weight was renamed priority
Execution loops were replaced by PluginFunctions.run() call
Use PluginPriority.HIGH and rename weight to priority
Try to run on previous Picard versions at normal priority.

Since there is no PluginPriority on previous Picard versions, this plugin will
raise an exception, better catch it and emit a warning.

Sophist said:
"It will work in most cases at normal priority, but any other plugins that run before it will get the old performers rather than the standardized performers.
Make version_to_string() and version_from_string() more tolerant

With those changes they can be used to parse plugin API versions too.

Test cases were modified accordingly.

Main changes:
```python
>>> version_from_string("1.0")
(1, 0, 0, 'final', 0)
>>> version_from_string("1.0.1")
(1, 0, 1, 'final', 0)
```
Reformat api_versions list, one per line, and note about order

Order is important since we have now a test case to prevent a lower version to be added.
Use version_from_string() and sets intersection to check API vs plugin versions

Logging was improved, showing plugin version and compatible API versions in debug mode.
When a plugin cannot be loaded due to incompatible API version log as a warning (was info).
No need to traceback on VersionError, just display an error

Traceback isn't useful in this case anyway.
Use path returned by imp.find_module() instead of module.__file__

It will display the source file path (.py) instead of the compiled file path (.pyc)
Log number of plugin names found in each directory
Log when a plugin conflicts with a previously loaded one.

Old one was silently replaced, this debug information will help to know
which one was replaced by which one.

Here is an example of log:
```
D: 12:29:36 Looking for plugins in directory '/home/zas/.config/MusicBrainz/Picard/plugins', 1 names found
D: 12:29:36 Module 'addrelease' conflict: unregistering previously loaded u'Add Cluster As Release' version 0.5 from '/home/zas/src/picard_zas/contrib/plugins/addrelease.py'
D: 12:29:36 Loading plugin u'Add Cluster As Release' version 0.5, compatible with API: 1.0
```
Merge pull request #4 from zas/PluginPriority

Improvements to plugin priority handling by @zas.
Use constants instead of hard-coded string and number.

"picard.plugins." -> _PLUGIN_MODULE_PREFIX

It also fixes a potential issue forgotten in 5c25d56b7 preventive fix.
Add a note about optional `priority` parameter in NEWS.txt