Make sdbmigrate friendly for simple projects

[drednout]

I propose a small set of improvements, which will make sdbmigrate for friendly for projects without sharded DBs, but with heavy schema usage:

1. sharding settings should become optional, by default shard_count may be equal to 1
2. add ability to configure schema to store sdbmigrate state - it's public by default, but sometimes public is not OK
3. ignore files with migrations with suffixes other than py/sql (e.g. vim tmp files break sdbmigrate)
4. add command for generating next empty migration - it's just handy and other migrators have such a simple feature
5. add ability to use sdbmigrate as a module for running with dynamic configs, received from HTTP API

[grepz]

Regarding 2: it should be optional, sometimes public access is needed, in case of external scripts.

[drednout]

sharding settings should become optional, by default shard_count may be equal to 1

8da1231

add ability to configure schema to store sdbmigrate state - it's public by default, but sometimes public is not OK

1bcdad3

add command for generating next empty migration - it's just handy and other migrators have such a simple feature

dbd2390
5cabc94

ignore files with migrations with suffixes other than py/sql (e.g. vim tmp files break sdbmigrate)

Won't do because it may causes problems in production environment with silent migration skipping. It will be better to have a small pain during development.

add ability to use sdbmigrate as a module for running with dynamic configs, received from HTTP API

Will be done in separate ticket. Scope is bigger, e.g. it would be great to make sdbmigrate convenient to use with cloud PostgreSQL, e.g. Neon or AWS.
=> #5

[drednout]

Done, released in version 1.1.0