Rust modules: Revise BTreeIndexBounds

[gefjon]

Description of Changes

• Make BTree filter operators reject owned values of non-Copy types, so that diagnostics prefer to suggest &x instead of x.clone().
• Restrict BTree filter args to a small set of types defined by our previous "Consistent filtering rules" proposal, per @RReverser 's request.
• Also make it so that String columns can be queried by &str arguments and ranges thereof.
• Add some comments to the macros that implement BTreeIndexBounds, because it's a doozy.

For reasons that escape me, this breaks inference on integer literals: they get defaulted too early to i32, even when the indexed column is of a different type like u32 or i64. We could potentially work around this by making i32 a FilterableValue for any integer column type, but that opens the door for some nasty truncation-related bugs. Failing that, we'll have to decide whether allowing &str for String, and owned values for Copy types, is more valuable than correctly inferring the types of integer literals (which would in that case be &0 instead of 0i64).

API and ABI breaking changes

BTreeIndexBounds is now less permissive than it was in the 0.12 release. Also the integer literal thing.

Expected complexity level and risk

3 - Complex macros and traits, but relatively contained. The only undesirable interactions I can forsee are other cases like the integer literal thing where type inference gets less reliable because we have more complex traits involved.

Testing

Describe any testing you've done, and any testing you'd like your reviewers to do,
so that you're confident that all the changes work as expected!

• Wrote a new test case in rust-wasm-test which demonstrates many combinations of valid args.
• Added some comments in the same place with some invalid combinations, and tested uncommenting them and seeing that they do not compile.

[coolreader18]

I guess if that's the direction we wanna go, these changes look good to me.