Add excel shorthand for Excel-friendly UTF-8 exports

[dereuromark]

Summary

Adds an excel config shorthand that flips the three options Excel needs to open a UTF-8 CSV correctly on Windows: BOM, CRLF line endings, and UTF-8 encoding. Addresses recurring "opens as mojibake in Excel" reports (see #132).

Why

Today users have to set three options individually:

'bom' => true,
'eol' => "\r\n",
'csvEncoding' => 'UTF-8',

…and remember to keep them in sync. Forgetting one is the most common reason a UTF-8 CSV opens as mojibake in Excel on Windows. The new excel => true shorthand collapses all three:

$this->viewBuilder()
    ->setClassName('CsvView.Csv')
    ->setOptions([
        'serialize' => 'data',
        'excel' => true,
    ]);

Other CSV options (delimiter, enclosure, setSeparator, header, extract, etc.) are independent and behave normally.

Implementation

• New default config key: 'excel' => false.
• New method _applyExcelPreset() that, when excel is truthy, calls setConfig() to force bom/eol/csvEncoding.
• Called from _serialize() (not initialize()) so the preset takes effect regardless of when excel is set — including the test pattern of constructing the view and then calling setConfig().
• README has a new "Excel-friendly UTF-8 export" section under Usage explaining the option and the equivalent individual settings.

Semantics

excel => true always wins for the three keys it controls. If a user wants a different combination (e.g. UTF-16, no BOM) they should NOT enable excel and set the individual keys themselves. Documented explicitly in the docblock and README.

Tests

Two new tests, all green:

• testExcelPresetEmitsBomCrlfAndUtf8 — excel => true alone produces a UTF-8 BOM, CRLF line endings, and UTF-8 output.
• testExcelPresetOverridesIndividualKeys — even when the user explicitly sets bom => false and eol => "\n", the preset still wins for those three keys (excel => true is a single switch by design).

Total: 19 tests, 37 assertions, all green locally; phpstan level 8 clean.

Notes on CI

The cs-stan job is expected to fail on this PR because of the pre-existing infrastructure issue that #147 is fixing (squizlabs/php_codesniffer v4 vs slevomat 8.29 incompatibility — reproducible on 5.x master). Nothing in this PR affects code style; merging #147 first (or rebasing this on top of it) will make CI green.

Independent of the bug-fix PR (#146 / #147) and the streaming proposal from the earlier deep-dive review.