Decide: keep ReSharper InspectCode (JetBrains CLI tool) for this repo's static analysis? #75

Spun off from the JetBrains.Annotations removal PR.

That PR dropped the JetBrains.Annotations library dependency. This issue covers the CLI tool that remains:

• `build/_build.csproj` has `` so the InspectCode tool is available locally during this repo's build.
• This repo's `Build` class implements `IReportIssues` (and `IReportDuplicates`), components that run InspectCode against the solution to surface static analysis findings.
• The framework also ships a `Fallout.Common.Tools.ReSharper` tool wrapper that lets any consumer's build invoke InspectCode the same way.

Two semi-independent questions

1. Does this repo's own build keep running InspectCode? Even if we don't use JetBrains as a library, the CLI tool is still useful for finding code smells if you're willing to invoke a JetBrains binary as part of your build. Removing it: drop the `PackageDownload`, drop `IReportIssues`/`IReportDuplicates` from `Build`'s implements list, drop the `InspectCode`-flavored release behavior.

2. Does Fallout keep shipping the ReSharper tool wrapper? Independently, we could keep the `Fallout.Common.Tools.ReSharper` JSON spec + `Generated.cs` so consumers who do want InspectCode in their build have a typed wrapper for it. Or drop the wrapper too (lose the convenience; consumers can still shell out).

Options

I'd nudge toward B if you want to leave the door open for consumers, A if you want a clean break.

Done when

• Decision recorded on each of the two questions
• If dropping the repo's InspectCode: remove JetBrains.ReSharper.GlobalTools PackageDownload, remove IReportIssues/IReportDuplicates from Build (and decide whether to delete the components from Fallout.Components too)
• If dropping the tool wrapper: remove src/Fallout.Common/Tools/ReSharper/, the matching test/Verify snapshots, the TeamCity ReSharperInspectCode import type