Consider adding support for Flyway R-versioned repeatable schema

[srcshelton]

As detailed in Flyway's documentation, Flyway has the concept of 'repeatable schema' which are re-applied whenever their checksum changes.

There are potentially several concerns with this concept: if non-idempotent statements appear in a repeatable schema file, then the state of the database would likely the lost on application; Flyway doesn't store a checksum of the file but a checksum derived from its internal data-structures, so any repeatable schema has to be fully tokenised in order to determine whether it should be re-applied (although we do store a SHA1 hash of the file in myway_schema_version, so we have a better situation here); it makes it much less obvious what state the database will be in at a point or over a period of time (although again we have the advantage as we store all executed statements in myway_schema_actions); and if your repeatable schema isn't version-controlled (or the history is lost) then it may no longer be possible to determine how the database attained its current state.

The myway metadata largely solves these issues, leaving the core question - if you're managing your schema migrations with myway, then does the concept of a repeatable schema really have a practical use (... and, indeed, would they warrant a new metadata directive to trigger repeatable schema from versioned schema)?

On the other hand, to maintain Flyway compatibility as much as is possible, all implementable Flyway features should really be supported.

[srcshelton]

Flyway Repeatable Schema are not that far removed from how myway handles Stored Procedures, in that the current version is always re-applied.

[srcshelton]

Repeatable schema files are named:

${repeatableSqlMigrationPrefix:-R}${sqlMigrationSeparator:-__}*\.${sqlMigrationSuffix:-sql}