Allow context keyword replacement to return CSS-safe value

This patch only converts the value to be CSS-safe.

[edit]
If this value is to be used as an HTML id or class, further processing is needed.
In the case of an id, drupal_html_id() needs to be called on the resulting value.
In the case of a class, drupal_strtolower() needs to be called instead of drupal_html_class(). The latter does only that in addition to drupal_clean_css_identifier() which is done in this patch.

* we should not filter out the underscore it is legal and has legitimate use cases (also see the d8 changenotice that underscores in nodetypes are no longer replaced with dashes in urls)

I allowed it primarily because the code mentions using Drupal's coding standards by default. However, I did not look at any D8 changes at that time and now I read #1109854: Overly aggressive transliteration in drupal_clean_css_identifier removes underscores from classes which highlights that issue. I also see now that Views allows the underscore with views_clean_css_identifier().

* we should not filter spaces and offer the possibility to pass multiple css classes (do wen need 'single clss safe' vs 'multiple css safe' options?)

I think a more flexible way is to pass in a seperator string . Either as an additional (but optional) option "css safe separator" or directly as part of "css safe". This can be used to explode(), convert and implode(). This should allow a more flexible multiple split when necessary, e.g. "Project Issue|Allow context keyword blah blah" => "project-issue allow-context-keyword-blah-blah" when you want only some space-separated substrings to become separate classes.

Off the top of my head, maybe something like:

if (!empty($converter_options['css safe'])) {
  if (is_string($converter_options['css safe'])) {
    $classes = explode($converter_options['css safe'], $value);
    foreach ($classes as &$class) {
      $class = drupal_clean_css_identifier($class, array(' ' => '-', '/' => '-', '[' => '-', ']' => ''));
    }
    $value = implode(' ', $classes);
  }
  else {
    $value = drupal_clean_css_identifier($value, array(' ' => '-', '/' => '-', '[' => '-', ']' => ''));
  }
}

So for single split use 'css safe' => TRUE and for multiple split use 'css safe' => '|'.

The idea where this patch came from is that you can use Ctools keywords to create class names in Panels. So if I wanted to use, e.g. "%node:type %node:title" it would give me "project-issue allow-context-keyword-blah-blah", where each keyword gets changed into a single class. I was thinking mostly in turns of 1 keyword = 1 class. But for example, if somebody wants to turn a multi-value term reference on a node into separate classes then it won't be possible. Though not a Ctools issue, this freedom makes the Panels issue (and other possible UI instances) difficult because now we will have to offer the user a choice between converting to single or multiple, and whether to do this per Ctools keyword or for the entire string of keywords. However, Ctools would then at least support it properly and the current Panels patch will still be OK but without the flexibility.

What do you think?