let us opt-in or -out of including parameter-names in generated method-names

[earloc]

As a developer, I want to configure if the source-generator should use parameter-names in the generated method-names, in order to no pollute my code base with redundant information when i prefer to utilize the identifer-keyed-approach when naming resources.

Currently, TypealizR uses the names of parameters to generate the method-name from it, mainly to support cases where an otherwise reduced method-name would end up as a duplicate. This is mainly useful when naming resources via the phrase-keyed-approach (which original usage of IStringLocalizer implicitly kind of forces us to do)

some-phrase-keyed.resx

<data name="Hello {user:s} xml:space="preserve">
 	<value>Hello {0}</value>
 </data>
 <data name="Hello {admin:s} xml:space="preserve">
 	<value>Hello {0}</value>
 </data>

would be generated to (pseudocode)

• Hello__user(string user)
• Hello__admin(string admin)

In scenarios where devs prefer the identifer-keyed-approach, the resource´s key presumably is unambigious enough, so that the parameter-name may be safely omitted from the generated method-name. (Fallback duplicate resolution would still apply, though):

some-identifier-keyed.resx

<data name="GreetEarly{user:s} xml:space="preserve">
 	<value>Good morning, {0}</value>
 </data>
 <data name="GreetLate{user:s} xml:space="preserve">
 	<value>Good afternoon, {0}</value>
 </data>

could be generated to (pseudocode)

• GreetEarly(string user)
• GreetLate(string admin)

As the intended usage cannot be inferred by any means, TypealizR should provide a configuration-switch which opts-out of using parameter-names in method-names.

Discussable is still, what the default-behavior should be, though. Switching from the current behavior might break existing code-bases, so this should be decided very carefully.