Updgrade Module::Install
Upgrade Module::Install::RTx for 4.0 compat
bump version to 0.04
I forgot to update CHANGES before 0.04.  oops
warning fix: PriorityAsSting may return undef
Allow restricting PriorityAsString to specific queues by name

Move /Elements/SelectPriority to /Elements/SelectPriorityAsString so we
can preserve the old behavior at times, and choose when to force the
dropdown.  Leaving @PriorityAsStringQueues empty preserves the old
behavior; as soon as it is non-empty, each call site examines their
queue and calls the appropriate component.
Allow per-queue priority configuration
M::I cruft
Make the README generate from the module

Clean up the one (mostly useless) code POD so it isn't in the README
(we apparently used to generate the README by hand from the module and
it had a weird out-of-context chunk in the INSTALL section)
Note the limitation of the new feature.

This hurts a bit if you have 20 queues with 1 config and 1 with a
special one, so we should be explicit about it.
Prep a 0.04_01 release
Fix simple %PriorityAsString configuration

69c1881 mistakenly changed the _PriorityAsString method to never check
the plain %PriorityAsString setting.  Change it to read from
PriorityAsString rather than from PriorityAsStringQueues.
Only call ->PriorityAsString if necessary
Explicitly state the Type of the configuration variables used

RT::Config->Get uses the Type of the configuration entry, as determined
from its META hash, to decide what to return in array contexts.
Additionally, RT::Config->Set explcitly alters the same Type based on
how it is called.  Thus for array values, in the absence of an explicit
Type, the ->Get method returns (undef) if it has never been ->Set, and a
(possibly empty) list otherwise.  This leads to ->Get being extremely
unreliable in hash contexts.

Explicitly set the Types of the three configuration variables used in
the extension.  This allows them to be reliably passed to ->Get in list
context, which simplifies their access considerably.  Notably, for
instance, the PriorityAsStringOrder variable no longer needs to filter
out undefined values, as were previously encountered if it had never
been ->Set.
Remove some commented out stub code
bump up MI
bump MI
Only use PriorityAsStringOrder for display

Any value of PriorityAsStringOrder which was different from the computed
set (by re-ordering or substraction of levels) would also cause the
levels for display to be incorrect.  Fix the algorithm to be independent
of the PriorityAsStringOrder setting, and update the documentation to
make it clearer that most use cases do not require setting it.
Get all of our default gitignores
Update README from lib/ and update lib to be even more explicit