Removing MonomialIdeal from top level

Short version: we can remove the type MonomialIdeal in the top level and instead install hooks on functions that have faster algorithms with monomial ideals that check if the input is a monomial ideal and if so use the faster algorithm. This is already accomplished for quotient, saturate, intersect, and annihilator in #1385.

Longer version: I understand that the Ideal vs MonomialIdeal dichotomy started a long time ago, and it makes sense that in the engine they can be stored differently, but I don't think they serve a good purpose at the top level anymore. The type Ideal can be changed to transparently store the ideals in the appropriate engine level object based on whether the ideal is actually a monomial ideal. Is there any issue with this?

Beside obvious programming pitfalls of dealing with different types, here are some issues with it:

i1 : S = ZZ[x,y];

i2 : isMonomialIdeal ideal "2x"

o2 = false

i3 : isMonomialIdeal monomialIdeal "2x"

o3 = true

i6 : E = kk[x,y, SkewCommutative => true];

i7 : monomialIdeal "x"
stdio:7:1:(3): error: expected a commutative ring

i8 : isMonomialIdeal ideal "x"

o8 = true

i13 : use S;

i14 : R = S/ideal"x";

i16 : monomialIdeal ideal "y"
stdio:16:1:(3): error: expected a polynomial ring without quotient elements

i17 : isMonomialIdeal ideal "y"

o17 = false

Why is it required that the ring be a commutative polynomial ring? I can imagine many places where lifting those requirements would actually be useful, e.g. when dealing with zero dimensional rings.