Move script profiling to profile/profile_traits crates

[connorimes]

Profiling was recently added for script tasks. To better understand how servo is behaving on the whole, this should probably be centralized with other profiling capabilities in the profile/profile_traits crates.

The profile_event function itself can probably be dropped as well and just use the profile function in profile_traits. If you need to access total time for an event (as it does now), enabling heartbeats for the category will track this.

@benschulz

[jdm]

The original motivation of the script profiling was to get a sense of where script tasks in particular are spending their time during periods of slow script responsiveness. This also allows us quite a bit of granularity, so I have vague concerns about merging that in with the higher level profiling for all the rest of the code. Am I needlessly worried?

[connorimes]

Are you concerned about performance overhead or just separation of granularities? Some of the categories currently in the profiler seem pretty fine-grained, e.g. PaintingPerTile. Others seem to have very short runtimes, like LayoutGeneratedContent or Compositing, while others have long runtimes like LayoutStyleRecalc.

If we think a better structure and separation of categories is needed, that's OK, but I think they should still be centrally located. This supports better consistency in profiling behavior and less code maintenance. Also, having a single place to look for profiling data should make life easier for those of us interested in analyzing it.

[jdm]

It's the separation of granularities that matters to me.