Co-authored-by: ZiriSut <rgebbid@gmail.com> (kab)

Co-authored-by: Selim Şumlu <selim@sum.lu> (tr)

Co-authored-by: Selim Şumlu <selim@sum.lu> (tr)

Co-authored-by: Grk <gu0townkg@relay.firefox.com> (tr)

Previously it was doing a lot more `calc`s because it was happening in
the parent div. This commit changes the box-shadow into an inset
box-shadow so we don't have to change the width all the time. But we
still need to change the width once to remove the left border for the
local tracks.

…ldren instead

Adding the border to the children, so we can right click on the left
track label and that would still open the context menu.

This PR fixes these track border/horizontal separator issues:

First commit fixes the issue where it's not right clickable on the blue
active thread indicator. It also tries to simplify this indicator by
removing a bunch of `calc`s.

Second commit fixes the issue that it's not right clickable on the top
border of the thread label.

Previously we were returning an object with hovered marker index and
label index. But we don't need that anymore since that was active tab
only feature. Now we can revert this and simply return a number instead
of returning an object and doing shallow object equality check.

Co-authored-by: Jim Spentzos <jimspentzos2000@gmail.com> (el)

Co-authored-by: Jim Spentzos <jimspentzos2000@gmail.com> (el)

Co-authored-by: Jim Spentzos <jimspentzos2000@gmail.com> (el)

Previously we were ordering the global tracks their global track order
by type. But if both global tracks were processes, we were simply
keeping the initial thread order. Now we sort the process global tracks
by their activity.

Previously we were only getting the first tab process main thread
as the selected thread, which wasn't the track we want most of the time.

…dIndexes

…al sorting behavior

This created some test changes how we find the selected thread in comparison
profiles especially. But after thinking about it, I decided that the new
behavior is actually better for them. Previously we were always getting the
first track, but now we are getting the crowded one, which is usually the
diffing track.

… process by default (#5491)

Previously we were keeping the original order in the profile data
structure when we were initializing the global track order, and
selecting the first tab visible process by default. But this was mostly
incorrect for the cases where we have more than one visible tab process,
because usually busier thread arrives later during the profile
collection.

This should help our users to see the most active process very quickly
instead of having to scroll down every time.

Fixes #5432.

Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>

Co-authored-by: Artem Polivanchuk <a.polivanchuk@outlook.com> (uk)

Updated locales: el, kab, tr, uk.

Thanks to our localizers for their contribution!