Currently, halo2 prevents the user from adding `Advice<PhaseN>` columns
if no column of the previous phase was defined before.

Since the first thing we need are the `Challenges` and these are placed
with `Phase2` we no longer can compile the code.
Therefore, a dummy column is added so that halo2 does not complain.
This should be solved in the future if the challenge API polishes this.

This introduces the challenge API inclusion into the Keccak Bit
implementation.
This carries 2 different challenges. one for the inputs and another for
the table-exposed value.

The changes consists on:
1- Swap the meta.advice_column for meta.advice_column_in(SecondPhase).
2- Replace the randomnes hardcoded now in the circuit by the Challenges.
Including it in the configure and witness_generation functions.
3- Test with a custom Challenges which has a fixed value.

I made an effort to migrate `Part<F>` and `PartValue<F>` to use the
`Value<F>` halo2 API. But since the struct doesn't implement `PartialEq`
it's challenging to do it. As I do need to operate with it quite a lot.

Also, there's another caveat which is that it feels really tricky to
extract the byte representation from a `Value<F>`. It feels like if
you're cheating to the API constrantly (using `.map()` to gain access to
the underlying F so that you can do extra things with it such as
decompose it into bytes).

For these reasons, right now `extract_field` was added. An issue will be
filled to track the tech-debt left here and pay it once we maybe we add
the required functionalities to `halo2::Value<F>`.

Now that all the three keccak implementations use the challenge API,
it's time to update the SuperCircuit to adapt to these new APIs.

…in tests