Move filter implementations from filter.module to plugin classes

Agree that we have to deprecate, several contrib.modules call _filter_autop at least, I didn't check the others but we should be consistent.

http://grep.xnddx.ru/search?text=_filter_autop&filename=

> I guess the question now is do we move the functions pretty much as-is to static methods, so contrib can call them more easily?

They were supposed to be private functions! It was clearly documented in D5/6/7 days that functions starting with an underscore are private!

Discussed with @joachim in Slack, we decided that instead of exposing the filters as static methods any callers should instantiate the plugin manager and then the specific plugin, e.g.

$text = \Drupal::service('plugin.manager.filter')
  ->createInstance('filter_autop')
  ->process($text, LanguageInterface::LANGCODE_NOT_SPECIFIED)
  ->getProcessedText();

We could perhaps shorten this to

$text = (string) \Drupal::service('plugin.manager.filter')
  ->createInstance('filter_autop')
  ->process($text);

Rebased.

Deprecations still to do.

The preg_replace() callbacks such as _filter_url_parse_full_links() should be deprecated too.