Docs: clarify benchmark suites — rename SharpTS.Benchmarks → SharpTS.Microbenchmarks, add READMEs

[nickna]

Why

The repo has two benchmark projects with near-identical names but distinct purposes, which made them easy to conflate:

	benchmarks/	SharpTS.Microbenchmarks/ (was SharpTS.Benchmarks/)
Question	Are we as fast as Node/Bun?	How close are we to the C# ceiling, and where's the overhead?
Compares vs	Node.js, Bun	Idiomatic C# (native-type ceiling) + "equivalent" C# (object?/boxing tax)
Tool	PowerShell + shared bench.ts	BenchmarkDotNet (in SharpTS.sln)
Scope	Whole-program, process-level	In-process per-function + allocation/GC profiling

They are complementary, not redundant, and can't be merged: BenchmarkDotNet must run in-process against managed code, while the cross-runtime comparison is black-box against the node/bun executables.

What

• Rename SharpTS.Benchmarks/ → SharpTS.Microbenchmarks/ (git mv, history preserved) to remove the name collision. All references updated: namespaces, usings, embedded-resource strings, SharpTS.sln, root SharpTS.csproj, doc mentions.
• Pin RootNamespace/AssemblyName in the csproj so the by-string embedded-resource names stay stable across future renames.
• Document the two-axis split:
  • benchmarks/README.md (external/competitive suite)
  • SharpTS.Microbenchmarks/README.md (internal/headroom suite)
  • new Benchmarking section in CLAUDE.md, parallel to Conformance Suites
• The shared benchmarks/scripts/lib/algorithms.ts stays byte-identical between the suites (embedded as SharpTS.Microbenchmarks.algorithms.ts).

Verification

• ✅ dotnet build -c Release clean (0 warnings, 0 errors)
• ✅ All 5 manifest resource names resolve to the strings the benchmark classes look up (the failure mode that compiles but throws at [GlobalSetup])
• ✅ dotnet sln list resolves the new project path
• ✅ git grep finds zero remaining tracked SharpTS.Benchmarks references

No functional/runtime code changed — rename + docs only.