precision_recall_fscore_support was getting gargantuan, because the similarities between the different input formats and metric variations weren't being exploited; rather, almost everything was special-cased. As a result, some bugs and inconsistencies crept in (admittedly on my watch as a reviewer).

This implementation:

• is much smaller and less nested in code, and should be faster in some cases, taking advantage of LabelEncoder to use bincount (and building upon vectorized multilabel support in FIX helper to check multilabel types #1985, ENH support multilabel targets in LabelEncoder #1987).
• deprecates pos_label and introduces neg_label, which allows micro-averaging to be interesting in the multiclass case (see ENH P/R/F should be able to ignore a majority class in the multiclass case #1983).
• neg_label has not yet been tested.
• to do so, will assume that multilabel indicator matrices are represented with <1 and 1 (or False and True)
• has not yet implemented support for the labels argument, largely because I don't know what it means (see DOC clarify the use of label in P/R/F metric family #1989). It's not hard to implement, but I wish labels were deprecated in favour of stating a convention regarding label ordering in the average=None case.
• has not yet fixed some broken tests for multilabel average='samples'
• has not yet updated the documentation or signatures of precision_score, etc. derivative functions regarding pos/neg_label
• currently assumes P and R go to 0 when their denominators are 0. I think this is incorrect behaviour, but it is backward-compatible (except with the average='samples' implementation; again, whoops): precision should be perfect when recalling nothing; recall should be perfect when there are no instances to retrieve. (And not realising that scikit-learn had adopted the 0 approach, I suggested in the documentation that 1 should be used.) The decision made elsewhere is to use 0 and warn. This is not yet implemented.