Adopt `core` naming conventions for bigint methods

[tarcieri]

See also: #537

The upcoming bigint_helper_methods feature of core defines method names and type signatures which it would be good to adopt here as well where it makes sense.

Here's a name bikeshedding thread, if anyone has any opinions on these names: https://internals.rust-lang.org/t/naming-bigint-helper-methods-bike-shedding/21688

[tarcieri]

I'd like to punt on this for the v0.6 release. We can always add the new names incrementally, deprecate the old ones, and remove them in a v0.7 release.

While I'm here though, I would also like to note some inconsistencies in modular inverse naming: we have inv, invert, and inv_mod, along with various inv_* and inv_*_mod names.

The *_mod is typically omitted when working with types that are implicitly modular like *Monty*, so that much seems okay, but the use of inv and invert seems a bit inconsistent at least.

Edit: hmm, I now notice this is used in a few places to make const fn inv unambiguous with an fn invert trait method, so I guess this is trickier to reconcile than I thought at first.

Edit again: these concerns probably apply to the Invert trait as well. I should perhaps split off a separate issue just for module inverse naming.

[fjarri]

Is this one going to be delayed until v0.7?

[tarcieri]

Yes, per my comment immediately above yours

[fjarri]

Sorry, I wasn't sure what "punt on this" meant.

[tarcieri]

Aah sorry, that is perhaps a little jargony. But yes, the plan is to introduce new names some time after the stable v0.6 release and deprecate the old ones.