Keep a persistent, thread safe state (resettable) of usable processors instead of depending on catching failure and retrying

[DiegoPino]

What?

This is related to #870

Right now, even if some processors do have a final static initialized flag (and error message) property on each class, the Processor Factory, based on the processor strategy depends heavily on catching initialization errors on each constructor. Ideally, which processors can be used could be gathered either statically (with a synchronized writer), maybe?, at the processor factory, with a reset method (also synchronized) triggered by a properties (configuration) reload and then used to "thin" down the list of processors available per format. Basically avoiding any attempt to create a processor object if its well know it won't work at all. E.g missing Kakadu, missing OpenJPEG, etc.

Given that our list of processors is really discrete, having also duplicated definitions of who are available at each strategy CLASS is a bit redundant.

I noticed we do have some final static synchronized properties and methods, and reading today on good practices for locks (Or avoiding locks), it does feel we could be inducing excessive locks by making accessors (reading) such, instead of just setters(synchronized).

This issue only implies some refactoring and new tests too

. e.g there is a method at https://github.com/cantaloupe-project/cantaloupe/blob/develop/src/main/java/edu/illinois/library/cantaloupe/processor/ProcessorFactory.java#L38 that is a synchronized getter that is also a setter. Ideally the getter would not be synchronized and we would need a synchronized setter. Funny, that method is ONLY used by the admin interface, when having that list available when selecting the candidates (a thinned down list of real available processors) would be great.

@jcoyne @glenrobson any comments/suggestions/concerns?