Feeds integration: support mapping option "language"

@joelpittet
Quick glance over I think it is mostly okay. I do notice that the made changes make Entityreference incompatible with Feeds versions older than 7.x-2.0-beta1 (the $values parameter is always an array since that version, but before that it was not enforced), but I don't think that is a problem. Feeds 7.x-2.0-beta1 was released more than two years ago.

1. Nitpick:
   

   +++ b/entityreference.feeds.inc
   @@ -62,17 +62,18 @@ function entityreference_feeds_processor_targets_alter(&$targets, $entity_type,
   + * @param \FeedsSource $source
   

   This the D8 style of documenting classes, not sure if this should be done as well for D7.
   Now we are at it, perhaps the parameters of entityreference_feeds_set_target() don't have to be documented at all as it is implementing a callback. The parameters are already documented in my_module_set_target() in feeds.api.php.

2. +++ b/entityreference.feeds.inc
   @@ -62,17 +62,18 @@ function entityreference_feeds_processor_targets_alter(&$targets, $entity_type,
   +function entityreference_feeds_set_target(FeedsSource $source, $entity, $target, array $value, array $mapping) {
   

   With typehinting the $value parameter to be an array, the following code lines become redundant and should be removed:

   // Assume that the passed in value could really be any number of values.
   if (is_array($value)) {
     $values = $value;
   }
   else {
     $values = array($value);
   }
   

   Note that $value parameter should then be renamed to $values as well (note the 's' at the end).

3. If you are ambitious, you could add an automated test for this functionality. There is an example for the email field module in #2672732: Feeds integration: support mapping option "language".