Add a blanket implementation for CustomSigFn

[aborgna-q]

• Adds a blanket CustomSignatureFunction implementation for closures, for we don't want to add a description.
• Drops the name and misc parameters, since they can be taken directly when creating the function along with the OpDef.

So we can just do:

let name = "MyOp".into();
let description = "".into();
let args = vec![];
let mut misc = HashMap::new();

let sig: Signature = todo!(); // Some complex computation
let signature = move |_args: &[TypeArg]| {
    Ok((sig.input.clone(), sig.output.clone(), ResourceSet::new()))
};

OpDef::new_with_custom_sig(name, description, args, misc, signature)

[acl-cqc]

• Adds a blanket CustomSignatureFunction implementation for closures, for we don't want to add a description.

Yes, very neat

• Drops the name and misc parameters, since they can be taken directly when creating the function along with the OpDef.

Ideally not - can you just make the blanket CustomSigFunc impl take and ignore those parameters?

My thinking is that if you might not be using a lambda - rather, that misc could be extra data that defines the op. So this would give yet another way of defining TKET1 ops: you have a Resource that has an OpDef for each different TKET1 op, but they all use the same CustomSigFunc which expects a serialized TKET1 op in the misc data.

(Thus: most of the specification is in the YAML, including the misc data and serialized TKET1 ops; the "self-registration" code just has to register the same CustomSigFunc for everything)

[aborgna-q]

Since OpDef always creates dyn CustomSignatureFunctions we can always do that specialization at initialization time.
In the case you mention, you can just create a TKET1CustomSigFn::new(name, misc) when creating the OpDef since you already have the exact same data there.

Doing only for the blanket impl with reduced parameters is a bit annoying. We can only define a single blanket impl (because Fn is a trait, so multiple Fns can clash) so it makes more sense to have it match the signature of compute_signature.

[acl-cqc]

I think that same argument says we should also remove misc from try_lower and then we might as well drop misc altogether? (If it's only for ops internal to the toolchain, rather than 3rd-party ops, then there's no need for it to go in the YAML!). That is, I think misc is useful so that a resource implementor can define the difference between ops in the YAML.

I don't see a problem with a CustomSigFunc impl only for Functions taking just the TypeArgs, note. (Sure, you could have variations, but I'm willing to bet that that's a common case.)

[aborgna-q]

I re-added the parameters in the trait method, but left them out in the blanket impl on closures as suggested.

[acl-cqc]

Sweet, thanks @aborgna-q.

FWIW I did try to allow a Fn directly in CustomSignatureFunc but didn't manage to get it to compile - this is a very nice way to get that working :)