implemented reporting of profiler data via scribe

@Wikia/platform-team pls review
Seems like there are multiple questions/points here: 

1. Should scribed functionality be split out from ProfilerUDP? 
I think this should be done 100%. I don't think the reason of
>I tried to reuse ProfilerSimpleUDP class to handle reporting via Scribe because it was the only one that is designed to send data to remote destination
Is a good enough reason to lump the scribed functionality into ProfilerUDP, especially since the code calls ```logDataScribe()``` and returns immediately after when ```$wgProfilerSendViaScribe``` is switched on. In this case, we're not even re-using the code to send data to a remote destination. 

Like @drsnyder suggested, I would expect ProfilerSimpleUDP to send data using UDP to some remote destination, and ProflerScribed to send data to scribed.

2. Should collecting/delivering the profiler data be separated into two classes?
Since these profiler classes are pretty straight-forward, I think de-coupling collecting/delivering is only beneficial for the sake of testing, which is something we should definitely try to do more of. I don't know if we'd ever match the xhprof collector with the UDP deliver-er, or something like that.

3. Race conditions when instantiating classes.
This code already suffers from this, since it seems to be able to call ```Wikia::log``` before it's included as well. I also don't think that there's a lot of opportunity for fatals to happen during the bootstrap phase - if we're having fatals in that area, we have bigger issues and monitoring the performance of requests that result in those fatals are the least of our worries :)