BroadcastQueue: fix subtle soft/hard timeout bug.

deliveryTimeoutSoftLocked() had been using mConstants.TIMEOUT for
clamping purposes, but that always ended up being the foreground
timeout, even for background broadcasts.

Fix this bug by passing through the actual ANR timeout value used,
and apply that for clamping purposes, making sure we're always
willing to up to double the original timeout.

Bug: 258204427
Test: atest FrameworksMockingServicesTests:BroadcastRecordTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueTest
Test: atest FrameworksMockingServicesTests:BroadcastQueueModernImplTest
Change-Id: I057f14f9c1055f99b5fd98e991a3d55cefcbd3bb