so far only "simple" pagination is supported by wuttaweb, so basically
the main feature flag, page size, current page. in this
scenario *all* data is written to client-side JSON and Buefy handles
the actual pagination.
backend pagination coming soon for wuttaweb but for now tailbone still
handles all that.
thankfully this is already handled and we can remove from tailbone.
although this adds some new cruft as well, to handle auto-migrating
any existing liburl config for apps.
eventually once all apps have migrated to new settings we can remove
the prefix from our calls here but also in wuttaweb signature
try to behave more like traditional tailbone, for the few things
supported so far. taking a conservative approach here for now since
probably other things are more pressing.
still opt-in-only at this point, the traditional tailbone-native
master is used by default.
new wutta master is not feature complete yet. but at least things
seem to render and form posts work okay..
when enabled, this uses a "completely" wutta-based stack for the view,
grid and forms. but the underlying DB is of course rattail, and the
templates are still traditional/tailbone.
this starts to get things more aligned between wuttaweb and tailbone.
the use case in mind so far is for a wuttaweb view to be included in a
tailbone app.
form and grid classes now have some new methods to match wuttaweb, so
templates call the shared method names where possible.
templates can no longer assume they have tailbone-native master view,
form, grid etc. so must inspect context more closely in some cases.
this check is happening not only for classic views but API as well,
which doesn't really have a theme.. probably need a proper fix in
wuttaweb but this should be okay for now
tailbone still defines the default menus, and allows for making dynamic
menus from config (which wuttaweb does not).
also remove some even older logic for "v1" menu functions
