Minor refactoring of route line view

[cafesilencio]

Description

Recently a customer asked for additional optimization around the process of selecting alternative routes. The rendering when redrawing long routes seemed longer than in the SDK's previous release. Although most of the rendering time is on the map side, this PR rearranges some of the calls to emphasize setting the line sources to get that process happening as early as possible. At the same time the calls to recalculate traffic gradients are executed on a background thread in parallel. This is a minor optimization. The bulk of the optimization is being explored on the map side.

Screenshots or Gifs

[cafesilencio]

@LukasPaczos please take a look when you have some time.

[codecov]

Codecov Report

Merging #5631 (4ee70b4) into main (12361fa) will increase coverage by 0.00%.
The diff coverage is 93.65%.

@@            Coverage Diff            @@
##               main    #5631   +/-   ##
=========================================
  Coverage     66.66%   66.67%           
+ Complexity     3692     3691    -1     
=========================================
  Files           569      569           
  Lines         23287    23302   +15     
  Branches       2656     2659    +3     
=========================================
+ Hits          15525    15537   +12     
  Misses         6802     6802           
- Partials        960      963    +3     

Impacted Files	Coverage Δ
...tion/ui/maps/route/line/api/MapboxRouteLineView.kt	94.93% <93.65%> (-0.80%)	⬇️

[LukasPaczos]

Wondering if by delaying the layer property updates we risk that a wrong vanishing offset will be applied to the new geometry, etc. That's why I'd prefer us to make the updates for sources and layers based on these sources as close to each other as possible. What do you think?

Refs #5688.

[cafesilencio]

Given the refactoring that is taking place to address: #5687, this PR has become irrelevant.