Requests for comment/Better PHP profiling

This RFC exists so we can investigate alternative profiling implementations to the one we have now.

Problems the DIY approach solves

 * 1) production debugging via ?forceprofile=1 and ?forcetrace=1

Problems the DIY approach doesn't solve

 * 1) DIY approach in MediaWiki is error-prone
 * 2) People forget to include closing profiling
 * 3) People have to remember to include profiling at all
 * 4) Things that might *need* profiling aren't
 * 5) DIY might be slower than something built into PHP

Proposal
Clean up the profiler implementation to decouple the profiling data collection from profiling output reporting. This will allow us to implement an XHProf powered Profiler class that coexists with the current MediaWiki profiling. We want them to coexist because: They can then both utilize the existing text/UDP output formats. Other output formats could be added as well without requiring a new base implementation.
 * xhprof does better function-level profiling than MediaWiki can
 * MediaWiki profiling does better on non-function-level units of work

Unsolved problems

 * ProfilerSimpleTrace is an odd duckling

Todo list

 * Separate data collection from reporting ✅
 * Implement data collection via xhprof ✅
 * Parser expansion (only used with ?forceprofile=1) less yucky ✅
 * Remove wfProfileIn/wfProfileOut from core classes for functoinal profiling - can probably do this now?
 * Deprecate wfProfileIn/wfProfileOut usage - once core is cleaned up :) ^^
 * Kill debug toolbar visualization experiment? - just remove profiling data from it ✅
 * Find someone interested in making nice visualization tools for xhprof data ✅
 * xhprof PECL module has some pages for this, but they are pretty crusty and only shipped in the PECL module.
 * Chad and Bryan both think that something useful could be built with Elasticsearch as the backing data store

Installation instructions
Manual:Profiling/Xhprof