Rework method chaining system of Rust generator

[QuantumSegfault]

Follow up to #1586

After testing, #1586 had some major flaws in practice

• In contrary to Rust idioms, the method chaining was done using &Self, which makes things like passing a method chain into a parameter expecting an own more cumbersome than necessary.
• It was a blunt instrument, being at best minor pollution, and at worst, a hindrance. Especially once the first point is addressed, forcing all void returns to be owning self (and by extension take owning self) was not practical.

This replaces the --enable-method-chaining switch with a --chainable-methods parameter, that works similar to the current async filter. You can choose to opt-in to it for all methods, for all methods within a particular resource, or just for a particular method (or any combination of those).

Additional, methods with method chaining enabled now take owning self instead of the default borrowing &self, and are -> Self rather than -> &Self. The ABI remains unaffected.

[QuantumSegfault]

@alexcrichton

Requesting review.

[alexcrichton]

For crates/core/src/chainable_method.rs it looks like that's more-or-less a duplicate of crates/core/src/async_.rs I think? Could those be deduplicated? Overall though I do think it's nice to have more fine-grained control over the configuration here.

For the implementation, personally I think returning &Self would be more suitable here because that still allows chaining and is still an idiomatic way of doing chaining in Rust. It's true that it doesn't allow returning something, so therading it all the way through would require a temporary, but personally I think that's reasonable (and is already the case for other builder-like patterns such as Command in the standard library).

Additionally for the implementation, would it make sense to give the FunctionBindgen structure access to the underlying Function? That way the return_self: bool parameter should largely go away since the function itself could be stored and then the predicate could be called on-demand.

[QuantumSegfault]

It is indeed a duplicate, but with a couple of changes (filter by resource; but no import vs export). They probably could be dedupped to an extent...not sure how easily though.

As for owning vs borrowing, in our use case its the difference between doing:

let command = Command::new(&["fly".to_string()], "Gives you the ability to fly.");

let with_speed = CommandNode::argument(
    "speed",
    &pumpkin_plugin_api::command_wit::ArgumentType::Float((Some(0.0), Some(1.0))),
);
with_speed.execute(WithSpeedExecutor);

let no_speed = CommandNode::argument(
    "target",
    &pumpkin_plugin_api::command_wit::ArgumentType::Players,
);
no_speed.execute(NoSpeedExecutor).then(with_speed);

command.then(no_speed).execute(BaseExecutor);

vs:

let mut command = Command::new(&["fly".to_string()], "Gives you the ability to fly.")
.then(
    CommandNode::argument(
        "target",
        &pumpkin_plugin_api::command_wit::ArgumentType::Players,
    )
    .execute(NoSpeedExecutor)
    .then(
        CommandNode::argument(
            "speed",
            &pumpkin_plugin_api::command_wit::ArgumentType::Float((
                Some(0.0),
                Some(1.0),
            )),
        )
        .execute(WithSpeedExecutor),
    ),
)
.execute(BaseExecutor);

Have to break up the chain in reverse order instead of being able to have one atomic builder.

EDIT: I cleaned up the "before" example to be a little more fair.

---

As for exposing Function directly...that might work. All depends if FunctionBindgen has everything else that is needed to give to the query.