…ods (francoispluchino)

This PR was merged into the 4.3 branch.

Discussion
----------

[Mime] Remove @internal annotations for the serialize methods

| Q             | A
| ------------- | ---
| Branch?       | 4.3
| Bug fix?      | yes (it's not really a bug)
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | ~
| License       | MIT
| Doc PR        | ~

Currently, when we extend the `Symfony\Component\Mime\Message` and `Symfony\Component\Mime\MessageRaw` classes of the Mime component, we get 2 deprecation messages:

```
The "Symfony\Component\Mime\Message::__serialize()" method is considered internal. It may change without further notice. You should not extend it from "Vendor\FooMessage".
```
and
```
The "Symfony\Component\Mime\Message::__unserialize()" method is considered internal. It may change without further notice. You should not extend it from "Vendor\FooMessage".
```

However, we need to add properties to the new class, and so, we need to extend `__serialize()` and `__unserialize()` methods in the same way as `Symfony\Bridge\Twig\Mime\TemplatedEmail`, to know, retrieve the serialization of the parent class:

```php
    public function __serialize(): array
    {
        return [$this->foo, $this->bar, $this->baz, parent::__serialize()];
    }

    public function __unserialize(array $data): void
    {
        [$this->foo, $this->bar, $this->baz, $parentData] = $data;

        parent::__unserialize($parentData);
    }
```

But given that the third-party components use another namespace, we get the 2 deprecation messages, while the 2 methods must be inevitably used and extended. Of course, the methods `serialize()` and `unserialize()` are always marked by the `@internal` annotation and the `final` keyword.

This PR so deletes the 2 deprecation messages that should not be displayed.

Commits
-------

8544a35 Remove @internal annotations for the serilize methods