Topic/typeconstraint allow string objects

[jrubinator]

Fix for RT#123299

[autarch]

Thanks for working on this. I took a look and I had some feedback.

[autarch]

We can't use MX::Types in Moose tests except as an optional dep, but I don't think you need to use MX::Types for this anyway.

[autarch]

This is very pretty, but we don't do this anywhere else in the code base, so I think it's better to just format this like everything else.

[autarch]

This is a little confusing. I think this would be better as Can use a stringifiable object as a type constraint failure message

[autarch]

It's a bit more verbose but I think it's better to write this as something like this:

my $stringifiable = subtype(
    as 'Str',
    inline_as { qq[Scalar::Util::blessed( $_[0] ) && defined overload::Method( $_[0], q{""} )] },
);

So there's a couple things there:

1. We don't need to define a bunch of new type names for this, just use anon types.
2. It's clearer to use overload::Method to figure out if something is stringifiable.
3. The type should be inlineable for speed.

Note that you also use anon empty subtype of Str for the coercion. But then I'm wondering why bother with the coercion at all. Is there any reason not to pass the object through as-is?

[autarch]

Then I realized I'm the one who suggested coercing to a string in the first place. But was that a good suggestion? I'm not sure. I can see arguments both ways.

[jrubinator]

Sorry for the delay on this (I was in Yosemite for at least part of the delay!) - I can see the argument for both as well. I personally would prefer to just pass the object through, but I think we're worried about backwards compatibility, correct?

[autarch]

@karenetheridge - what are your thoughts here? I would argue that returning a stringifiable object is fine as a change for a major release.