See if we can remove partial precomputation

[AaronFeickert]

Currently, the only reason to require a custom curve library fork is to support partial precomputation. This permits a more flexible use of inner-product generators.

While it's beneficial to have this flexibility, it's a headache for integration with other libraries. It might be useful to revisit this design choice and see if it can be removed in favor of being able to use the upstream curve library directly. This has become increasingly relevant since upstream has seen a flurry of activity that continues to diverge from the fork.

For use cases in the Tari ecosystem, it's unlikely to cause efficiency problems in practice. For use cases elsewhere that do require a larger inner-product generator set than is used in verification, there are options. Either the caller generates parameters for the aggregation factors it actually needs (which incurs no internal efficiency hit), or we allow for a larger generator set but pad the corresponding scalars (which does incur an efficiency hit).

[AaronFeickert]

This entire issue would be rendered moot if an upstream curve library PR is accepted. However, it's been stuck in the queue for many months, and it's not clear if it will be merged.