Preparatory commit for adding playback control and sync via
GNU Rocket for demo-making purposes.

This introduces a new '--with-rocket' configure flag, the default
when unspecified is for rocket support to not be included.

No integration code exists yet, but this makes available the
necessary parts of the GNU Rocket library to start on that.

There probably needs to be more work on configure/build side
since the Rocket code has some platform-specific ifdefs of its
own we're not currently managing.  I'd rather not run their
full-blown build if possible, considering how small the library
bits are to integrate.  We should really be able to get away with
more or less what's done in this commit.

Rocket integration will need a more precise form of going from
time->[order,row].

It's odd to have the divide by 1000 in the csf_get_length() loop
anyways, when elapsed is already computed milliseconds.  So even
without Rocket in mind, this commit seems desirable, if minor.

This commit more or less just normalizes everything involving
song time to use milliseconds, converting to seconds at time of
use where that's what's desired.

This adds a --with-rocket configure flag for enabling
experimental GNU Rocket support in Schism.

When enabled in the build, a series of new runtime flags are
added:

--rocket (enable rocket mode)
all these overrides imply --rocket:
--rocket-host=HOST_OVERRIDE
--rocket-port=PORT_OVERRIDE
--rocket-bpm=BPM_OVERRIDE (beats per minute)
--rocket-rpb=RPB_OVERRIDE (rows per beat)

BPM and RPB are RocketEditor concepts, which the GNU Rocket
protocol is totally ignorant of.  But they're provided to aid in
keeping the Editor and Schism in agreement on what Rocket row
maps to what millisecond within the song and within the Rocket
track data.  This doesn't override the speed/tempo setting for
the song within Schism, and you'll have to take care to pick
values such that they align with the Rocket bpm/rpb values.

If you want the RocketEditor's patterns and current row to align
with Schisms.  It's a little awkward due to how IT defined the
speed/tempo semantics.  According to IT.TXT these are the rules
for Axx/Txx (speed/tempo):

 Axx   Set Speed.

       I prefer to think of this command as "Set Frames per Row".
       Normally, the tracker operates at around 50 frames a
       second. If the rows were played at this speed, then a huge
       amount of space would be required to enter the pattern data.
       Instead, setting the 'speed' of the song will cause the
       tracker to wait on the current row for 'xx' frames. Hence,
       setting the speed at 50 (decimal = 32hex) will cause each
       row to last about a second - quite a long time! The default
       is A06. The initial speed can be set in the variables
       screen on F12.

 Txx   Set tempo to xx

        Valid ranges are between 20h and 0FFh. The higher the
        value, the faster the playback. This essentially
        determines the time length of each frame, by the following
        formulas:
                      Frames per minute = 24*Tempo
        equivalently:
                      Frames per second = 0.4*Tempo

Which means you can determine the appropriate --rocket-bpm via:
24*Txx/Axx/RPB

So the schism default of 6/125:
24*125/6 = 500 rows per minute
with a "rows per beat" of 4, the bpm would be 125

What's an appropriate --rocket-rpb depends on if you want equal,
more, or less resolution in the rocket tracks than the schism
pattern data.  It's convenient to make them map 1:1, but if you
use a higher --rocket-rpb (preferably that's a multiple of the
rpb you're using in schism patterns), then you get more Rocket
rows per Schism row.  This can be necessary for getting enough
precision in scheduling visual events, especially if Axx is high
(more time is burned per schism row the higher Axx is).

Another complication here is dynamic Axx/Txx changes in the song.
No attempt is made to change the --rocket-rpb/bpm values mid-song
or anything.  You just set it once @ startup and that's a
constant.  So you probably want to avoid using those in demo
songs, or be prepared to deal with the wonky alignments in the
RocketEditor.

As-is this commit only attempts to connect to the Editor once at
startup.  So you'll need to have RocketEditor running before
starting SchismTracker w/--rocket.  This area could be made more
robust before merging upstream into SchismTracker, but it is
already usable.  If viewed as an experimental demo developer
mode, this is probably good enough to merge as-is.

See emoon/rocket#165 for more context on
what this is all about.