Add ToConstraintFieldGadget bounds to CurveVar and FieldVar

[winderica]

Description

This PR adds the requirement that structs that implement CurveVar or FieldVar should also implement ToConstraintFieldGadget, which could be convenient e.g. when we want to extract the underlying FpVars from a generic CurveVar without specifying + ToConstraintFieldGadget<...> every time.

Since both implementations of CurveVar (i.e., SW ProjectiveVar and TE AffineVar) and all implementations of FieldVar (i.e., FpVar, QuadExtVar, CubicExtVar, and EmulatedFpVar) already implement ToConstraintFieldGadget as well, this PR does not introduce any change in the behavior of existing code.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests (N/A)
• Updated relevant documentation in the code (N/A)
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer

[Pratyush]

I think a semantically cleaner version of this would be to add x() and y() operations to the CurveVar trait.

[winderica]

@Pratyush Yeah that makes sense! Will add these methods, as well as xy(), to CurveVar.

But I still think adding ToConstraintFieldGadget to CurveVar is beneficial. x() and y() are called more likely for exposing the details of the point, while a developer may invoke to_constraint_field() without caring about the implementation details (e.g., whether the result contains infinity, which is true for SW points but not for TE points). What do you think?