Completely reworked device manager

The new model basically builds an object-oriented layer on top of MM's
JNI. It's fast enough for us, but there are a few weird kinks to work out
yet. Especially for the Picard motors, which have a stepping precision of
1.5um, not everything works like we might expect (in particular, the
rotational axis calibration is now broken -- or has it been for a while?).

The biggest thing left to do is rewrite the motor sliders to use motor
steps behind the scenes: the labels will read in um (or degrees, for the
twister), but moving the motors by 1 or 10 um (i.e. by clicking the
buttons with or without shift) will move by however many *steps* bring the
motor closest to that delta.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Make 'titled' method generic.

Don't know why I didn't do this earlier. Saves a lot of trouble casting
the types around.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Added SteppedSlider; supersedes MotorSlider & pals

The old MotorSlider, along with its Integer(Slider)Field and
LimitedRangeCheckbox, used to provide stage controls. However, with the
recent upgrades to the device manager, we needed something more flexible
-- a slider that ostensibly operated in floating-point (note the
'ostensibly' -- more on that in a moment) and could be rescaled for any
kind of stage.

Hence the introduction of the SteppedSlider. It converts a range of
doubles with a known step size into a range of integers, hidden behind the
slider interface. It also wraps up the increment/decrement, limit-range,
and updateable text box features into a single class (though the text box
can be moved wherever you like).

Technically, the slider does *not* operate in floating-point. This is more
or less the point, though; pressing + should increment by the minimum
possible motor step -- for Picard motors, 1.5 um. This can vary, but is in
general NOT a single unit of '1'. Integers don't work for this. So the
slider maps a range of integers onto multiples of the step size. It's
imperfect, and the solution to the cyclic update loop is inelegant, but it
works, and it *feels* clean.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Cleaned up plugin UI construction

I condensed the slider creation into a utility function, since the stage
sliders were all more or less the same; this also dodges some NPEs if MM
starts with an invalid setup (i.e. trying to get the stage's current
position when there was no stage). This also replaces the IntegerField
with a good old-fashioned JSpinner (after the previous commit,
IntegerField was only being used for the Z settle time control).

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
SteppedSlider enhancements and fixes

trySetValue no longer goes through with it if the value is the same. This
needs to happen in some places, but trySetValue -- used by the timer motor
updates in SPIMAcquisition -- isn't one of them, and it was interfering
with the ability to enter and go to values.

I got rid of the horizontal struts in the value/range box at the bottom of
the slider; for some reason, these were increasing the box height
significantly. If they look too awful, I'll put in a 4x1 fixed box...

The initial value of a DoubleField is now rounded as well. A minor fix,
but it annoyed me.

I added functions for getting the current minimum and maximum of the
slider. Still no way to set the rounding. :(

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Moved step size to DAL

The Picard stage step sizes are now properties of the devices. They're
editable while the system is running, though such editing would likely
lead to bizarre effects.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>
Changed slices to use um

Almost forgot about these! Technically they were using um anyway, but now
they multiply their numbers by the Z step size (provided it's available on
start-up -- this might need fixing!) so you don't go to any
non-integer-multiple positions.

Signed-off-by: Luke Stuyvenberg <stuyvenberg@wisc.edu>