Change default escaping of str_getcsv() and fgetcsv() to empty string

There's only 2 places will left after parent issue fixed

core$ git grep str_getcsv -- core/lib
core/lib/Drupal/Core/Mail/Plugin/Mail/PhpMail.php:101:        $value = str_getcsv($value, ',');
core/lib/Drupal/Core/Mail/Plugin/Mail/SymfonyMailer.php:130:            $value = str_getcsv($value, ',');

We're not really using this on CSV data but rather as a way to:

        // Split values by comma, but ignore commas encapsulated in double
        // quotes.

I wonder what happens an email address contains \\

FWIW I'm pretty sure that this code is incorrect because

$value = '"te,st"@example.com,test2@example.com';
$value = str_getcsv($value, ',');

results in a value of

[
    'te,st@example.com',
    'test2@example.com',
]

whereas I'm pretty sure we should be leaving the quotes in, ie...

[
    '"te,st"@example.com',
    'test2@example.com',
]

Interestingly \Drupal\Tests\system\Kernel\Mail\MailTest::testFromAndReplyToHeader seems to prove things are working as expected - BUT you cannot set Drupal's mail address to "mail@test"@example.com - which is valid according to https://github.com/egulias/EmailValidator/blob/4.0.2/tests/EmailValidato... so it's hard to properly test.

Looking for RFC I got answer from GPT

Escaping should be reconsidered for email parsing: While RFC 4180 is the standard for CSV files, parsing email addresses should follow the more specific email RFCs (5321, 5322). If str_getcsv() no longer handles escape sequences, a custom parsing function or a more specialized library like Egulias's EmailValidator might be required to handle these cases properly.

For #5

So looks like here 2 options:
- set escape: "\\" with comment referencing RFCs for quoted part of email (which can be anything, even comment)
- delegate parsing to some library

but surely it needs a test at least for '"te,st"@example.com' which should not become 'te,st@example.com'

parent commited so the issue unblocked