Simplify hints declaration and make frontend responsible for number of outputs, not hint / backend

[gbotrel]

Creating this one as draft before cleaning it as it opens a discussion. It reverts some changes introduced by #183 #175 (cc @ivokub ).

Essentially, this PR proposes to remove nbInputs and nbOutputs set in StaticHintFunction and the NbOutputs() function in the Hint interface.

Trying to implement multi-outputs (with variable length) hints for binary operation, this declarative way is really not helping;

1. The circuit developer will provide a list of inputs to the hint function (example; api.NewHint(myHint, input0, input1, ...). IF (and I don't think we need to) we want to check that the number of inputs matches what the hints can process, it's up to the hint to perform the check (ie if len(inputs) > ... --> error). Currently this was encapsulated in a Call function.

2. Similarly, the circuit developer knows how many outputs it expects from a hint. He should set it like so bits := api.NewHint(BitsHint, 220, value) would return the first 220 bits for example in []bits. Previously this was done declaratively at hint definition, through NbOutputs() method, which was called both in the frontend and the backend at solving time. --> it makes no sense as the backend will not decide the number of outputs, the frontend did at compile time and created the exact number of wires needed.

@ivokub did you have specific future scenario in mind when doing this pattern?

[ivokub]

Creating this one as draft before cleaning it as it opens a discussion. It reverts some changes introduced by #183 #175 (cc @ivokub ).

Essentially, this PR proposes to remove nbInputs and nbOutputs set in StaticHintFunction and the NbOutputs() function in the Hint interface.

Trying to implement multi-outputs (with variable length) hints for binary operation, this declarative way is really not helping;

1. The circuit developer will provide a list of inputs to the hint function (example; api.NewHint(myHint, input0, input1, ...). IF (and I don't think we need to) we want to check that the number of inputs matches what the hints can process, it's up to the hint to perform the check (ie if len(inputs) > ... --> error). Currently this was encapsulated in a Call function.
2. Similarly, the circuit developer knows how many outputs it expects from a hint. He should set it like so bits := api.NewHint(BitsHint, 220, value) would return the first 220 bits for example in []bits. Previously this was done declaratively at hint definition, through NbOutputs() method, which was called both in the frontend and the backend at solving time. --> it makes no sense as the backend will not decide the number of outputs, the frontend did at compile time and created the exact number of wires needed.

@ivokub did you have specific future scenario in mind when doing this pattern?

NbInputs was already removed from the hint.Function interface before. It was really a leftover in hint.StaticHintFunction construction.

I added separate function for computing the number of output wires for cases when the number of outputs is non-trivial and is computed by some other function. For example, for ternary decomposition the number of outputs is ceil(log_3(modulus)) and it may be error-prone if the user computes it by hand. But, thinking now, we most probably do not want to encourage users to use such complicated hints directly and should rather refer them to use a gadget which provides (correctly) constrained version of them. I'm all good with removing NbOutputs.

In that context - with the creation of std/math / std/math/bits, would it make sense to make the built-in hints internal? Hints considered harmful?