Refactoring: Improve inconsistent core pickles variable names

[volhovm]

As per the Least Authority's audit and subjective experience, it would be a good idea to improve naming of the core Pickles (and Kimchi) variables. This issue is only for the ones that are particularly confusing -- there is much more that can be done.

Examples include (non-exhaustive)

• xi/r same as u/v same as polyscale/evalscale -- the u/v can be used in Latex docs, while code can use just polyscale/evalscale. I suggest removing xi/r because it's less descriptive, and also because u/v is already used in the docs + in Plonk paper.
• b is just a terribly non-descriptive variable name for a quite a complicated thing (a combined evaluation)
• x_hat is the same as public_Inputs and sometimes public_evals. I prefer the longer descriptions in the code, while the latex docs can have \hat{x} if needed.
• prev_challenges: PrevChallenges is actually not challenges, but challenges /and/ commitments. It's quite confusing.

[jspada]

Nice ideas