option to override monomial order in leadTerm, gb, etc.

Nobody has claimed this yet.

This feature likely requires engine changes to do correctly, but I wish it was possible to override the ring's monomial order in calls to leadTerm or gb, without making a new ring and mapping everything over.

I understand that having rings tied to monomial orders as first class objects is pretty much a Macaulay2 truism, so I'm wondering if there are cons to having the monomial order be a separate argument in every call in engine or even top level (but of course a default order can be cached, so not every caller needs to specify the order).

This is particularly convenient in areas where working with different monomial orders simultaneously is useful.

Start by tracing the engine and top-level implementations of leadTerm and gb, then review how rings and monomial orders are represented and passed today. Compare the implications of a separate order argument with creating a new ring, and define the API and engine behavior needed to support simultaneous monomial orders before implementation.

Written by the indexing model from the issue text.