`baby_fto` definition is missing `Bv` move

[lgarron]

./script/cubing-def baby_fto doesn't produce it, I'm not sure why yet. (Twizzle Editor supports it.)

[rokicki]

This is a good point. For all puzzles, the rotations produced are not redundant on an axis; for every axis, we produce exactly one rotation move. So for instance on the 333, we produce Rv (which we call x), but not Lv (which is just Rv').

For twizzle editor and twizzle explorer, the move swizzler classes know how to generate moves that "make sense" according to SiGN into actual permutations from the move permutations that are given, so all those moves (and many others, such as 22-27U on a 99x99x99) work fine, without having to explicitly generate them beforehand (which is entirely impractical for a 99x99x99).

This can be annoying when using pg-generated output (ksolve, gap) outside of twizzle editor and twizzle explorer. One fix may be to stand up a "move expander" specification that can be separately implemented in Rust and/or C++ to do the same thing that happens in the Javascript.