Make enum methods values and valueOf unmappable

[NebelNidas]

Taken from QuiltMC/enigma@fe9c232, QuiltMC/enigma@1d8067c and QuiltMC/enigma@226d5b0.

Fixes #330.

[modmuss50]

Idk what this test class is doing?

[NebelNidas]

Sorry, this should have remained a draft since there were some issues in my cherry-picking. Force-pushed the rewritten commits now so that we don't have the tests in yet, I'll add those under the correct packages in a later PR

[NebelNidas]

@liach What do you dislike about this PR? 🤔

[liach]

Such preventions are quite pointless; we do't prevent renaming equals, enum entries, record components, or other overrides either

[NebelNidas]

Shouldn't Enigma do this though?

[liach]

We have cases where we rename an override chain inferable through record component names. IMO marking these gray through name proposal service would be better, especially that these names can inadvertently cause troubles due to proguard works and we wish to rename in such cases

[NebelNidas]

OK, I'll close this PR then and commit the constructor remap fix in a new one

[NebelNidas]

... we do't prevent renaming equals ...

What does this do then?

Enigma/enigma/src/main/java/cuchaz/enigma/EnigmaProject.java

Lines 133 to 134 in c4a79cf

	} else if (name.equals("equals") && sig.equals("(Ljava/lang/Object;)Z")) {
	return false;

Also, while it's not explicitly disallowed to rename values and valueOf yet, Enigma doesn't support it anyway either... So adding the check to isRenamable doesn't restrict anyone, instead it would accurately report if Enigma supports renaming the passed element or not

[modmuss50]

Change is fine, this could maybe refactored to not allow remapping stuff from Java? Or maybe a larger change where we have a classpath of none re nameable libraries im not sure. Needs some discussion first if we want to do it.