Allow more inputs for gens(::UniversalPolyRing, ...)

[lgoettgens]

using @varnames_interface with a small workaround.

Due to weirdness with this macro between modules and inclusion order, I distributed the macro calls to respective files.

[lgoettgens]

This seems to be breaking, as it changes the return value of gens(S, ["y", "z"]).
If nobody has an idea how to fix this, I'll be abandoning this in a few days

[fingolfin]

What changes about the return value of gens(S, ["y", "z"]) ? Is it that it is now a tuple and would become a Vector ?
Ah I see, so code that does y,z = gens(S, ["y", "z"]) would then break?

In general it strikes me as being more consistent with what we do everywhere else: gens(R) always returns a Vector for our other rings. But yeah it'd be breaking

Perhaps a better API going forward would be this:

function (a::UniversalPolyRing)(b::VarName)
  return gen(a, b)
end

function (a::UniversalPolyRing)(b1::VarName, b2::VarName, bN::VarName...)
  return Tuple(gens(a, [b1, b2, bN...]))
end

Then one can write

julia> x = S(:x)
x

julia> y, z = S(:y, :z)
(y, z)

And here S(:y, :z) would indeed always return a tuple, even if gens might return a vector.

[fingolfin]

However, we should also be a bit wary about breaking existing code. E.g. this would break the GenericCharacterTable package

[lgoettgens]

No, the problem is that gen(S, ["y", "z"]) used to return (y, z). Changing this to [y, z] would be mostly fine (haven't checked with GCT). But the way all of this varnames stuff works would change it to ([y,z],) (1-tuple of this vector), which is too weird to handle correctly