Refactor benchmarks

[fdcastel]

Based on #1200 for now. I will rebase it with latest master in the future.

• Rename project Perf to FirebirdSql.Data.FirebirdClient.Benchmarks.
• Update project to use .NET8.
• Upgrade BenchmarkDotNet to version 0.14.0.
• Update baseline nuget package to v10.3.1.
• Add /BenchmarkDotNet.Artifacts folder to .gitignore.
• Pass command-line arguments to BenchmarkDotNet engine.
• Apply SQL Formatting. Use raw strings.
• Add script run-benchmark.ps1.

[fdcastel]

Rebase with master.

[fdcastel]

Following up on the initial refactoring, these additional changes were made on the branch:

Infrastructure

• Extracted a shared BenchmarkConfig : ManualConfig class to eliminate the duplicated inner Config class that existed independently in each benchmark class. Job configuration is now defined in a single place.
• Extracted a BenchmarkBase abstract class holding the ConnectionString, CreateDatabase(), and GlobalCleanup() members that were duplicated across benchmark classes.
• The connection string can now be overridden via the FIREBIRD_BENCHMARK_CS environment variable (falls back to the existing localhost default), enabling use in environments with a non-default Firebird setup.

Configuration

• Updated the benchmark toolchain from .NET 8 to .NET 10, matching the project's TargetFramework.
• Removed WithPlatform(Platform.X64) and WithJit(Jit.RyuJit) — both are no-ops on .NET 8+ (x64 + RyuJIT is the only supported configuration) and were just noise.
• Added MarkdownExporter.GitHub so each run automatically writes a GitHub-flavored Markdown table to BenchmarkDotNet.Artifacts/, ready to paste into issues or PRs.
• Added DefaultOrderer(SummaryOrderPolicy.FastestToSlowest) to make the results table easier to scan.

Benchmark methods

• Single-value [Params(100)] and [Params(100_000)] replaced with plain constants — a single-value [Params] adds a column to the results table without varying anything.
• Fetch methods now return the last read value instead of discarding it, to make dead-code elimination by the JIT impossible.
• Added async variants (ExecuteAsync, FetchAsync, OpenCloseAsync) for all sync benchmarks. Async ADO.NET paths have different allocation profiles (state machines, Task wrappers) and are the primary path in web workloads.

New benchmarks

• ConnectionBenchmark — measures connection open/close throughput (sync and async), which exercises connection pool logic.
• LargeFetchBenchmark — added to the committed tree (was previously an untracked file).

Script

• run-benchmark.ps1 now accepts -Benchmark ConnectionBenchmark in addition to the existing values, and two new optional switches: -Disasm (enables --disasm) and -Profile (enables ETW profiling on Windows).

Documentation

• Added docs/benchmark.md describing prerequisites, how to run, connection string configuration, available benchmarks, and where results are written.

[fdcastel]

Future improvements:

1. async benchmarks
2. connection-pool benchmarks
3. configurable connection string
4. Remove Duplicated config (use a shared base)

[fdcastel]

Rebased onto latest master.

[fdcastel]

Added a couple of benchmark improvements prompted by #1272 (the UTF8 CHAR fetch allocation regression). The lesson from that investigation: the regression lives only in the fixed-length CHAR(n) CHARACTER SET UTF8 rune path, but the default CommandBenchmark only covered BIGINT and VARCHAR(10) UTF8, so it never surfaced there — it was visible only via the opt-in LargeFetchBenchmark. These changes make the default suite catch that class of regression and make the results easier to read.

What changed (commit 46db5a1)

• CommandBenchmark: added CHAR(100) CHARACTER SET UTF8 to the DataType params. This covers the read/truncation path in Fetch/FetchAsync automatically.
• CommandBenchmark.Execute: Execute/ExecuteAsync now send a column-sized string (via a small SampleValue() helper) instead of a bare integer, so the write/validate rune-count path is exercised too — previously it was never benchmarked.
• docs/benchmark.md: corrected the NuGet baseline description (it claimed "latest published" but the project pins a specific released version; it now documents the pin plus a bump-per-release note), added an Interpreting results section explaining that for these I/O-bound benchmarks the Alloc Ratio (not the noisy Mean) is the primary regression signal — using Major performance degradation introduced with 10.3.3 (UTF8 char fetch) #1272 as a worked example — and listed the new data type.

Effect — the default benchmark now catches #1272

Running CommandBenchmark on this branch, local Core100 vs the released NuGet100 baseline:

DataType	Allocated (baseline → local)	Alloc Ratio
BIGINT — Fetch	46.3 KB → 50.9 KB	1.10
VARCHAR(10) UTF8 — Fetch	50.2 KB → 54.8 KB	1.09
CHAR(100) UTF8 — Fetch	187.7 KB → 1805.1 KB	9.61
CHAR(100) UTF8 — FetchAsync	209.6 KB → 1825.1 KB	8.71
CHAR(100) UTF8 — Execute	409.5 KB → 759.9 KB	1.86
CHAR(100) UTF8 — ExecuteAsync	977.9 KB → 1329.1 KB	1.36

Only the CHAR UTF8 cases regress; BIGINT and VARCHAR stay at ~1.0, which also matches the root cause (only DbDataType.Char goes through the rune-truncation path). These ratios reflect the current provider code on master — once the fix from #1252 lands they should return to ~1.0.

CI is green across FB30/FB40/FB50.