feat(ops): Fallible fast ops

[aapoalas]

Add support for fast ops to fail at any (sync) phase. If a fallible fast op returns an Err variant, the fallback option will be set true and the error gets saved to OpState. V8 will immediately, synchronously call the normal binding function, and the #[op] macro takes care of injecting a check for saved errors at the top of the binding.

The op macro and especially its fast side is starting to get pretty ugly, and this makes it uglier still. Big points of ugliness and undefined behaviour:

1. In normal op side, the OpState borrowing is done several times at worst. There is no combined logic to figure out if OpState is needed and if it is needed as shared or unique (mut), thus leading to multiple places needing to borrow it individually.
2. With fast call codegen, the FastApiCallbackOptions is starting to get quite confused about when it should be added into the inputs.
3. Worse yet, if an op explicitly requires a Option<&mut FastApiCallbackOptions> parameter AND returns a Result or uses OpState, then the macro will generate two mutable borrows or one mutable and one shared borrow for the FastApiCallbackOptions, breaking Rust rules. This is likely "safe" in that its currently not used anywhere and its unlikely that it could lead to any issues since this is all synchronous code and thus race conditions are not possible. Still, it's not correct and shouldn't really be like this.

A further point that should be pondered is if it's correct to add fast_op_error into OpState or if it would be better to just use the gotham state with some core, or perhaps ops/lib.rs, defined FastOpError(Err) type.

[littledivy]

LGTM

[littledivy]

Can you add an example in core/examples/? faillible fast ops are not used anywhere so don't have a full test for this right now

[aapoalas]

Can you add an example in core/examples/? faillible fast ops are not used anywhere so don't have a full test for this right now

There are probably a lot of fallible fast ops already around, since fast op generation is now automatic. We just don't know which ones as its automatic :)

[littledivy]

Ah right...the #[op(fast)] attribute is only to enforce now?

[aapoalas]

Ah right...the #[op(fast)] attribute is only to enforce now?

Yeah. I'm planning on introducing a #[op(!fast)] to deny.

[aapoalas]

This PR should now be ready to merge.