Port CSharpUseLocalFunction analyzer/tests to shared layer

[mavasani]

First commit: file moves
Second commit: xlf and resx changes

Porting the code fix is blocked on #43056

[CyrusNajmabadi]

Porting the code fix is blocked on #43056

I would prefer to not move then...

If someone turns this on, but can't fix, that seems unfortunate :(

[mavasani]

@CyrusNajmabadi the code fix is still available from the fixer that ships with IDE. It is just not available in NuGet package, so will not be available if executing a fix outside VS (for example some command line tool or VS code or such).

[mavasani]

Ping @CyrusNajmabadi - let me know if you disagree with the justification.

[CyrusNajmabadi]

Ping @CyrusNajmabadi - let me know if you disagree with the justification.

I don't like it. I think we should not do this if we can't move the whole feature over (analyzer and diagnostic). I worry that we'll just end up with crap left behind that we never get to. But not moving this at all, it highly motivates solving this in an appropriate manner.

[mavasani]

I don't like it. I think we should not do this if we can't move the whole feature over (analyzer and diagnostic). I worry that we'll just end up with crap left behind that we never get to. But not moving this at all, it highly motivates solving this in an appropriate manner.

From an end-user perspective, this will make no difference at all. They just need the analyzer on CI, and code fix in IDE (regardless of whether it is invoked from a NuGet package or from an implementation in IDE). My point is, do we think it is worth blocking a user feature (CI enforcement) on just the fact that we'd like to cleanup and port the fixer to NuGet package?

[mavasani]

@CyrusNajmabadi Can you review based on the discussions in meeting today? This PR is just moving an existing analyzer + tests to shared layer. Code fix port is blocked on CodeGeneration service becoming a public API.

[mavasani]

Thanks!