bug #27903 [Lock] fix lock file permissions (fritzmg)

This PR was squashed before being merged into the 3.4 branch (closes #27903).

Discussion
----------

[Lock] fix lock file permissions

| Q             | A
| ------------- | ---
| Branch?       | 3.4
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | see discussion below
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

See [this comment](https://github.com/symfony/symfony/pull/27668#issuecomment-403392924). Since we are using `r+` now to fix an issue on Solaris, we also need to change the file permissions when the lock file is created for the first time. Otherwise
```php
fopen($fileName, 'r+')
```
will fail due to the file permissions and while
```php
fopen($fileName, 'r')
```
will work, the subsequent locking will again fail on Solaris.

Changing the file permissions to `0666` fixes this issue. __However__ any lock file that was generated _prior_ to this change will still cause issues and would need to be manually deleted. Usually the default `sys_get_temp_dir()` location is used for the lock files and _usually_ these files are purged periodically, so it probably won't matter that much. But it still might cause some confusion since it will not be transparent, why the file lock failed on Solaris systems.

Commits
-------

23481a112e [Lock] fix lock file permissions

src/Symfony/Component/Lock/Store/FlockStore.php

@@ -81,7 +81,7 @@ class FlockStore implements StoreInterface
         set_error_handler(function ($type, $msg) use (&$error) { $error = $msg; });
         if (!$handle = fopen($fileName, 'r+') ?: fopen($fileName, 'r')) {
             if ($handle = fopen($fileName, 'x')) {
-                chmod($fileName, 0444);
+                chmod($fileName, 0644);
             } elseif (!$handle = fopen($fileName, 'r+') ?: fopen($fileName, 'r')) {
                 usleep(100); // Give some time for chmod() to complete
                 $handle = fopen($fileName, 'r+') ?: fopen($fileName, 'r');