fix: add startup workaround for trainwreck query bug

not at all clear why, but c621e21cd4b4a2a408d8a32ace0b34afe6fdf526 has
introduced some strange bug where the "first" trainwreck query will
raise an error and yet subsequent queries work fine.

so now in the startup sequence we simply force a query, which for
unknown reasons does *not* raise any error, and will somehow magically
prevent the error when a "normal" trainwreck query happens later.

AFAIK this is a "benign" operation and causes no real side effects
other than preventing the strange error. fingers crossed, this is
fine and will not cause further problems...??!

feat: move some app model logic to wuttjamaican

previously the "canonical" way to get the model was via
config.get_model() - but now the canonical way is simply app.model

note that for now, even though wuttjamaican provides a default model,
the rattail model does not (yet?) inherit from it. also since
wuttjamaican does not yet support versioning, that feature remains in
rattail only for now.

various legacy things have been deprecated and will warn if used by
other apps.

fix: refactor code so most things work without sqlalchemy

also refactor tests to help ensure that remains true

Add `AppHandler.next_counter_value()` magic

this is now used by `BatchHandler.consume_batch_id()` and hopefully is
able to auto-magically create a dedicated counter table if the
underlying db engine is not postgres. at least that part seems to
work for tests using sqlite