Migrate back to generic type parameter

[bjacotg]

Do not merge.

Attempt at fixing #323

[hovinen]

Oh dear, don't I feel sheepish. Seems I'll have to update the blog post.

I'd really like to understand why it works now and not before. Perhaps because we then incorporated the and() and or() methods into Matcher itself rather than using an extension trait?

More importantly, will we end up shooting ourselves in the foot again with this change? We should make sure we understand its implications really well before deciding to merge.

[bjacotg]

Yep, I agree. I started playing with this option considering it will be a trade-offs between Matcher::and(...) and fixing #323 and maybe getting a better understanding of the issue. But everything seems to work so I kept playing.

After a quick test with the proto library, it does work, so seems promising! But, I won't submit this anytime soon. I will have to write a nice looking doc and deep dive a little further.

For the explanation of why things did not work at the time, the move away from the extension trait looks like a good candidate. I will investigate further.

[bjacotg]

Just came back from time travelling. Moving from the trait extension to the Matcher trait did not solve the issue. However, using PhantomData to force ActualT as a paramter of StrMatcher does solve the issue. See this PR.

So, using associated type does not solve the issue by itself, but it forces the StrMatcher to use PhantomData, which solves the issue. I think.

It's too late for me to draw any conclusion to all of this. I will get back to it next week.

[bjacotg]

Closing this PR.