Make LabelEncoder more friendly to new labels

This PR intends to make ``preprocessing.LabelEncoder`` more friendly for production/pipeline usage by adding a ``new_labels`` constructor argument.

Instead of always raising ValueError for unseen/new labels in ``transform``, LabelEncoder may be initialized with ``new_labels`` as:
  * ``"raise"``: current behavior, i.e., raise ValueError; _to remain default behavior_
  * ``"nan"``: return np.nan for unseen/new labels
  * ``"update"``: update ``classes_`` with new IDs ``[N, ..., N+m-1]`` for ``m`` new labels and assign
  * ``"label"``: set newly seen labels to have fixed class ``new_label_class=-1``

Tests and documentation updates included.

(edit: adding ``"label"`` to list for quick summary)
What if, as @jnothman pointed out, ``min(new_class_values) < max(self.classes_)``?  ``np.searchsorted`` wouldn't work in that case.

To summarize my thoughts with this:
* We need to support repeated calls to ``transform`` that have new values, which rules out a new/old ``searchsorted``.
* To make sure we can support repeated calls, I added a unit test (the failing one).

My opinion is that we ought to keep a dictionary ``self.new_class_mapping_`` that maps from values that weren't in ``fit`` to new class labels during ``transform``, which will ensure that repeated calls to ``transform`` will map new values consistently.

If no one feels strongly against the performance impact of falling back to dictionary access for handling the unseen values, I'll implement this later today.