[FrameworkBundle] Rename WebTestCase to FunctionalTestCase

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | yes
| Deprecations? | yes
| Tests pass?   | TBD
| Fixed tickets | None
| License       | MIT
| Doc PR        | symfony/symfony-docs#2514

This idea came to me while reading the Cookbook article [How to create a Console Command - Testing Commands](http://symfony.com/doc/master/cookbook/console/console_command.html#testing-commands) and I wanted to hear feedback from others before submitting a patch.

Basically the Cookbook article states that when testing a Command that extending `WebTestCase` is a good way to get access to the Kernel and thus the Container. This struck me as weird because I was wanting to test a Command, which doesn't really have anything to do with "the web."

Currently `WebTestCase` doesn't do anything internally that looks like web-specific work, and the class docblock itself states "WebTestCase is the base class for functional tests.".

I'm not sure how far-reaching this class is used by others, so I'm not sure on the BC implications. I think we could go one of two ways:

1. Rename WebTestCase to FunctionalTestCase, thus removing WebTestCase. Add a note in the `UPGRADE` documentation to note the new class name and action required by someone upgrading their application. This issue should be noticed pretty quickly by anyone upgrading as their test suite would break. But finding the easy fix in `UPGRADE` should require little work from project owners.

2. Move WebTestCase to FunctionalTestCase, then change WebTestCase to extend FunctionalTestCase but contain no functionality. Then add a `@deprecated` flag for WebTestCase to be removed in Symfony 2.4 after 2.3 LTS. This would ensure all existing bundles using WebTestCase would still work, but we could encourage a more-properly named class starting in 2.4.

Do you agree, and if so, which method sounds best?

**EDIT 1:**
@beberlei made a great third suggestion below that I think is better than the two above:

3) Extract a new class `KernelTestCase` from `WebTestCase` and instead allow WebTestCase to extend KernelTestCase. Pull all methods up into KernelTestCase except `createClient()` because `createClient()` is focused solely on creating a Client for issuing web-based requests.

Benjamin's solution provides us a clear extension point from `KernelTestCase` for Command-based tests and also provides 100% backwards-compatibility without the need to deprecate WebTestCase.