Allow copying a ParameterizedTypeName with new type arguments

[ansman]

This fixes #1139

[Egorand]

Thanks!

[ZacSweers]

From an API standpoint I wonder if it would be better to have a withParameters instead. These overloaded copy functions are brittle historically

[ansman]

I'd be OK with that too. In fact I was probably going to add a mapTypeArguments in my project too.

[Egorand]

IMO copy is easier to discover with it being a Kotlin pattern. What's causing brittleness, the fact that it's hard to change in a backwards-compatible way?

[ansman]

If we are keeping copy I think it might make sense to expose the enclosing type and add both that and the raw type to the copy method.

[Egorand]

@ansman I'd be reluctant to expose those simply for consistency, without a use case. If there is a use case then we'll consider it.

[ansman]

My current use cases are:

• Creating a wildcarded typename.
• Mapping Java types to Kotlin types (List, Set, Annotation etc).

This isn't possible in all cases without exposing these things.

[ZacSweers]

Can you add a test case that wasn't possible before? The one here is possible with the previous API

[ansman]

Done

[ZacSweers]

This seems ok to me, though that example has me 🤔🤔🤔

[ansman]

Yeah, the example isn't perhaps real since you'd access this as Map.Entry<...>. I essentially needed a nested class and the enclosing class needs to be parameterized to test the specific case.