Profile: Minor fixes. Signal handling fix.

[IanButterworth]

Addressing some post-merge review suggestions from #44185 (review)

[IanButterworth]

@vtjnash I've seen some rare instances of this kind of behavior on linux with regular profiling

julia> @profile begin
           sleep(1)
       end

======================================================================================
Information request received. A stacktrace will print followed by a 1.0 second profile
======================================================================================

Also there are some spurious info request prints in the linux CI, where the only ones Profile triggers are sent to an io buffer, so something is unintentionally triggering these.
https://buildkite.com/julialang/julia-master/builds/8929#ed106d69-576a-4584-bdb7-4c45a0288f83/282-813

Given SIGUSR1 is now multipurpose, I think it's that running = 0 is being declared too early and some straggling timer-emitted signal gets confused for a user-sent one.

I suspect the issue may be that the timer might still spit out a signal after timer_delete returns, which AFAIU is explained by https://man7.org/linux/man-pages/man2/timer_delete.2.html

The treatment of any pending signal generated by the deleted timer is unspecified.

So I added the 93dce80 to add some buffer to let a stray signal pass before declaring running = 0

There may be a better way to do this, or my understanding may be flawed.

[IanButterworth]

There may be a better fix than what is described in #44199 (comment)

But I think it would be good to get these in given there are unexplained intermittent failures on package_linux64 which didn't happen here.

[IanButterworth]

Hasn't appeared to fix the spurious triggers on linux
https://buildkite.com/julialang/julia-master/builds/8977#55fe445b-9756-4357-9f75-5048cbd202e8/281-803

Perhaps the sleep is too short?