NF(+RF): AttributePermutator got option strategy with new handling for uattrs value

if strategy="uattrs" is specified, then attributes are not simply
permuted breaking any possible existing interdependency -- samples
of the same unique combination of attrs obtain the same attrs value
of another unique combination.  In the simplest case, e.g. if
attrs=targets, it results in simply remapping targets (i.e. e.g.
1 becomes 2, 2 becomes 1 and 0 stays 0).

The idea is that this should be closer to the idea of "permutting
independent samples" as "clean" permutation MC H0 testing requires and
hopefully would eliminate the necessity for the scary two-stage design
to not permute "testing" labels.  With this setup, in case of balanced
labels, it should be ok to simply reassign labels in all functional runs
gaining similarly concervative H0 distribution (yet to be tested)
ENH: while looking at MulticlassClassifier -- minor typos + 1 more test
NF: core Node obtains additional parameter "pass_attr"

The purpose is to allow enriching resultant dataset (output by __call__) with
information from original dataset or the state of the instance's .ca.
Unfortunately postproc is not fit for the purpose since original dataset is not
even provided into it, only result.  Also providing such functionality via this
API change should not have significant performance impact but could come useful
in many scenarios.

ATM it also is capable of storing the content of .ca attributes of the instance
itself BUT only as .sa attributes since it lacks any idea what they should
correspond to.  We might like to consider extending ConditionalAttributes with
a parameter describing either they correspond to samples or features of the
result or may be adding some syntax into specification of pass_attr to describe
which collection any particular element should be copied to (e.g. a dictionary
{'sa' : [...]}.

Such feature should also enable more sophisticated postproc calls which
would make use of those passed additional attributes, happen that is needed.

Basic untitest test_multiclf.py:test_multiclass_classifier_pass_ds_attributes
gives an example.  Original intent was to father ca.raw_estimates but those
ATM are  in the transposed "shape" (classifier x samples).
ENH: when unable to resolve ties -- choose first one in sorted order

on one hand it is just making it somewhat worse (e.g. before it could be
considered random resolution since order of labels comes from a unordered dictionary)
but this way we should obtain results consistent with LIBSVMs failure to resolve
ties.  So -- for now lets be more consistent with LIBSVM.  Correct resolution still TODO
ENH: expose Multiclass's ca.raw_predictions also as a ca.raw_predictions_ds with correct orientation

Felt wrong to break meaning of what/how things are presented in raw_predictions.
But classifier x sample was not a good fit for pass_attr, so came up with
new .ca.  Having it as a Dataset allows to disambiguate what targets
actually corresponded to any given binary classifier's 'positive/negative' labels
DOC: typos
ENH: due to a brain-freeze initiating a mvpa2.sandbox with multiclass.py

it just contains few functions for dealing with pair-wise classification problems.
Could not formalize correctly, and probably anyways that first asks for the RFing
of the ConfusionMatrix etc first
ENH: test_multiclass_pairs_svm_searchlight usecase test demonstraing/testing extraction of pair-wise accuracies from Multiclass SL
BF: comparison to pairs being defined
BF: (tests) some basic fixes for issues detected with daily_tests
BF: make BoostedClasssifier.clfs immutable (tuple)

    since we rely on processing _set_classifiers, we should not allow changing it in-place
ENH: IterativeFeatureSelection -- allow pmeasure to be None
ENH: ProxyMeasure -- add skip_train parameter

If we proxy a classifier, which was also used in sensitivity analyzer, we might
like to skip actual training since clf would be trained already.  We just need
to mark the Node as trained.

This parameter might float up eventually into one of the super classes
ENH: first shout at RFELearner -- helper to run most common RFE analysis

based on splitting training data and running nested CV with RFE
to figure out optimal number of features to stay with, and then
running RFE on full training dataset.

TODO: most probably separate "Learner" is not necessary and we should just get
a derived FeatureSelection to be used with a FeatureSelectionClassifier to avoid
too much of custom constracts (e.g. for sensitivities)
ENH: make root __repr__ ignore prefixes listed in __init__doc__exclude__

also includes some missing/fixed docstrings
BF: fixed up __repr__ and __str__ for the MappedClassifier
RF: RFELearner -> SplitRFE feature selection

This way it becomes a more generic/flexible FeatureSelection to be wrapped within FeatureSelectionClassifier
BF: reset __init__doc__exclude__ to empty again in StaticFeatureSelection
BF: adjust unittest to allow full path to the partition
ENH: extend unittest for sensitivity with checking if pass_attr on .fa is in effect