Drop old debug globals and configs

[cconard96]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	-

[cedric-anne]

I simplified a bit the code by computing durations without using the Profiler. There is no need to add complexity to the Profiler usage to just make a $start_time - $end_time calculation.

[cconard96]

The ability to use the profiler as a regular timer should stay I think. There is at least one specific use case where it is better than manually computing
Currently, dashboard cards show a duration when in debug mode but it only covers one portion of the work done to load them. With the profiler, we can start a timer in the AJAX code, and then retrieve the duration at the time the HTML is generated.

[cedric-anne]

The ability to use the profiler as a regular timer should stay I think. There is at least one specific use case where it is better than manually computing Currently, dashboard cards show a duration when in debug mode but it only covers one portion of the work done to load them. With the profiler, we can start a timer in the AJAX code, and then retrieve the duration at the time the HTML is generated.

The problem here was that the Profiler was used outside the debug mode, and it was necessary to introduce some logic to bypass existing limitations, eg the $force_start param:

    /**
     * @param bool $force_start If true, the section will be started even if the user is not in debug mode.
     *                          This is useful if the profiler is going to be used to simply time a section of code and
     *                          the result will be used in the application.`
     */

I am not against giving the ability to get the execution time of a given section if it is easy to use for the developper and does not introduce too much complexity.
If it permits to enhance the dashboard profiling, then this change would be welcome, but please do it in another PR to simplify reviews. It would probably not conflicts with current changes.