Theories failure messages describe enum arguments unhelpfully

Theories are great, and they've been helping me produce some really nice tests, but now I want to define theories on every value of an enum, and failures here are quite tricky to debug because the error messages aren't too useful. 

The unit test in this acts as a good example. It defines an enum, uses enum.values() as `@DataPoints` and then contains a theory called theoryTest that fails for one of the enum values. The error message this gives is `ParameterizedAssertionError: theoryTest(allValues[1])`.

This isn't that helpful, since the enum could be ordered in any way and still be broadly equivalent (and if it's coming from external code, the order could happily change arbitrarily). This is particularly annoying when you have a massive enum, want to check a theory for all values in it, at which point this error becomes entirely useless until you manually debug the theory, or count one by one through the current enum values. I've been retrofitting some theories around some old code with some fairly large enums, and this is not a fun place to be. By definition though, enum values already have meaningful names, and it'd be better if these were used, giving errors like `ParameterizedAssertionError: theoryTest(BAD_VALUE)`.

(In addition there's the specific enum case, where the datapoint is `@Datapoint public static ENUM enumValue = ENUM.A_MEANINGFUL_NAME`. Here the message blames `theoryTest(enumValue)`. That's not useful, and this is really only useful if you reliably name the datapoint variable holding your enum the same as the enum value's name anyway. Less annoying, but since it already has a real name that should describe it perfectly well already, it would be good to use that)

Attached code now does all of this, using the enum name (via toString(), since the Enum docs recommend using that instead of .name()) instead of the variable name, if the variable refers to an enum or array of enums. Enums seem like an acceptable special case for this, since they're a base Java type that's already a value with a name by definition. Sound reasonable?