…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