I do not think we will end up with one super-terrific-optimal-for-all-workloads
path-selector. As result, people or vendors may wish to plug into dm-mpath and
use the exsiting dm path selectors. This is currently not possible because the
init funciotn and path status knowledge is stuck in the path-selector. Hey, that
was my fault so I will kick myself in the shins :) If we thought we will have a
single ps to rule them all then I guess we could add some way for vendors to
plug in there. However, as the subject of mail hints to the following patches
are based on the assumption stated at the beginning of the mail.

The goal of seperating out the priority_group stuff is so vendorX can implement
a pg or (internally) a collection of groups and define functions
like pg->init to send their failover commands or handle special
error cases. The latter is not really possible today becuase how to get, decode
and/pr pass vendor specific sense is not defined. Also, by seperatng the
HW specifics from the path-selection vendors can resuse dm's path-selectors.

01-sep-pg-from-mpath.patch - move some pg code out of dm-mpath.c. dm-mpath.c
still parses some args like how it does of selectors, but there is a new table
format: