…nBeEnabled to canBeDisabled (fabpot)This PR was squashed before being merged into the 3.3-dev branch (closes#21196).Discussion----------[FrameworkBundle] changed some default configs from canBeEnabled to canBeDisabled| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | n/a| License       | MIT| Doc PR        | n/aFrameworkBundle configuration is currently "optimized" for when a projectdepends on symfony/symfony (which is the vast majority of Symfony projects outthere as that's how Symfony Standard Edition is set up). As all components arealways available, features (forms, validation, translation, serializer, ...)are disabled by default in FrameworkBundle's configuration (`canBeEnabled`) anddevelopers must enable them when they need them (that was done mainly forperformance reasons).That's annoying as it means one configuration step before being able to useforms for the first time (or validation, or serialization, or translation, ...).To make features auto-configurable and make the framework a bit moreuser-friendly (that's where I think I need to invoke DX :), I'd like Symfony 4to work in a different way. Instead of relying on symfony/symfony, I wantpeople to install only the components/bundles they need. In that scenario, wecan auto-configure Symfony FrameworkBundle based on the available components.If you add symfony/form as a dependency, then it makes sense to automaticallyenable the feature in framework bundle (with the possibility to disable it ifneeded thanks to `canBeDisabled`).Let's recap: * Before:   * You want to use forms; you have symfony/symfony, so nothing to install;   * Using forms does not work out of the box though; you need to know that you     have to edit `app/config/config.yml` to explicitly enable forms;   * Forms work! * After:   * You want to use forms so you install symfony/form (like for any other     packages out there; want to use Twig for templating, install twig/twig);   * But for Symfony components, there are no other steps; forms are     auto-configured just because you installed the dependency, go work now!In a way, it makes handling/installing/configuring Symfony components nodifferent than doing the same for a third party package. That's about relyingeven more on Composer and less on configuration. Symfony components have theextra benefit of being auto-configured via FrameworkBundle. That's not the casefor other third-party packages/bundles, but for those who attended SymfonyConBerlin, you know that this is coming soon via Symfony Flex.That's even more interesting for forms as CSRF protection needs an extra knobto be turned on currently. With the new way, just install the CSRF securitycomponent. An again, you still have the possibility to turn it off if you wantto.Anyway, this PR gives us the flexibility to do both: when usingsymfony/symfony, everything works as before, if you are usingsymfony/framework-bundle, then auto-configuration based on the installedpackages is automatically activated.This also brings consistency as this behavior is already what we've done forthe Doctrine Annotation library in 3.2.Last, but not the least, with all the work currently done on the containerlazyness for Symfony 3.3, concerns about performance are less important thanbefore, so having components auto-enabled when installed should not be a bigdeal. We might even go one step further and remove enabling/disabling forESI/SSI/fragments/... And whenever we create an independent Session component,we will be able to do the same with the session configuration. The astutereader might have noticed that I haven't talked about the templatingconfiguration, but as the component will be deprecated in 3.3, I prefer to keepits activation explicit.In terms of BC, the only change is for people using symfony/framework-bundlewith some packages that were installed but not enabled in the config. I wouldsay that this should be pretty rare and anyway, the only consequence is a smallperformance hit which can be easily offset by explicitly disabling the config.That's all folks!Commits-------ef80873 [FrameworkBundle] changed some default configs from canBeEnabled to canBeDisabled98ce21a [FrameworkBundle] changed the default value of annotation setting based on the existence of Doctrine Annotations

This PR was merged into the 3.3-dev branch.Discussion----------[TwigBundle] Disable form in tests| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | n/a| License       | MIT| Doc PR        | n/aTests are broken with high deps due to the changes made in#21196> Symfony\Bundle\TwigBundle\Tests\NoTemplatingEntryTest::testSymfony\Component\DependencyInjection\Exception\LogicException: Form support cannot be enabled as the Translation component is not installed.> Symfony\Bundle\TwigBundle\Tests\NoTemplatingEntryTest::testSymfony\Component\DependencyInjection\Exception\LogicException: The Validator component is required to use the Form component.This will fix them.Commits-------2a279b9 [TwigBundle] Disable form in tests