Separate out the sniffing for extract().

[jrfnl]

Currently only VIP checked for the usage of extract(), even though it is an explicit rule for core.

Ref: https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#dont-extract

Solves #90 for real ;-)

[JDGrimes]

Why not give the sniff a more generic name, so that other functions can be added in the future? Maybe just Restricted instead of DontExtract?

[JDGrimes]

I guess this relates to #582.

[jrfnl]

Why not give the sniff a more generic name, so that other functions can be added in the future

@JDGrimes I followed the handbook - it has a separate section all to itself, so it seemed appropriate to name the rule after the section.

I'd rather have these kind of sniffs more modular and pluggable as - yes - noted in #582, rather than have all of them jumbled together.
That will also make for less backward compatibility breaks for these kind of sniffs.

[JDGrimes]

@jrfnl I've decided that you are right and we should keep these sniffs more modular. However, I would add that this will impact performance as we reprocess the tokens for every single child sniff. This ought not so to be. We should refactor the parent sniff so that it only processes each token once. It could keep an index of functions that it found, and then if a child sniff flagged a particular function, it would have stack pointer for all of the times in the file that that function was used already saved from when it processed the functions previously. (Or possibly there is a better way to do this?) Anyway, that is for its own issue.

[jrfnl]

@JDGrimes Made a very small start with some efficiency improvement for the AbstractFunctionRestrictionsSniff in #615