[Security] Making the component more flexible

[ghost]

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	yes
Deprecations?	yes/no (not sure yet)
Tests pass?	yes
Fixed tickets	none
License	MIT
Doc PR	none, yet.

This is the initial beginning to refactor a large part of the Security component. As purposed by @wouterj I start the initial refactoring. (cc: @nicolas-grekas)

[wouterj]

Actually, I would do this just the other way: First remove/deprecate everything you'll find with User in this component. Then, we can reintroduce some user related features using this identity.
It'll be quite a challenge though, so I think it's better to split this into multiple PRs:

1. Deprecate Token#getUser() and remove its usage in the component in favor of the other token methods;
2. Deprecate UserProviderInterface and it's usage in the component and bundle;
3. Introduce the IdentityInterface and build a BC layer between UserProviderInterface and the IdentityInterface.

[javiereguiluz]

Actually, I wouldn't start with code for such a huge and difficult task!

This is what I'd do:

• Make a list of the features that the Symfony component must and must not support by default. Lots of things have changed since the component was created. Some practices are now deprecated ("salting" passwords manually) and other edgy practices (2FA) are now common enough to be included in the core.
• Show examples of how all those features would look like with the new code, so we can compare it with the current situation. For example, getting an object that represents the logged user or persisting users in the database are critical operations that must be solved perfectly. If the new systems is "better" but makes these common operations much more complicated (for the sake of "code purity") then it's a big "no go".
• Finally, when you know what do you want to do and how it's going to be ... then you can code it. This is just a detail. Anyone with experience in PHP can do it. The important thing is the design of the new system.