List Branches: Make processing with start/limit params more performant

The 'List Branches' project rest endpoint has a 'limit' parameter.
Regardless of whether or not it's used, we open the repository, load all
branches, and check for the user's visibility over all branches.

We rework the implementation such that we do the following
  1) Get all branches
  2) Filter out branches that don't match 'matchPrefix', 'matchRegex'
  3) Iteratively loop over remaining refs, check for visibility until we
     get a fill of 'limit' count (taking 'start' param into account)

Unfortunately, for 'start' parameters that are larger than zero, we need
to check visibility of refs up to the 'start' value, and only then start
populating the output list until we get a 'limit' number of refs. This
means that requests with large 'start' will be less performant, but at
least we improve over the status quo, where all requests check
visibility for all refs.

We also had to rework the sorting implementation of refs to ensure this
change is a noop: Previously we performed the sorting as follows:
  1) Get all branches, filter for visibility
  2) Sort the o/p list
  3) Filter it out again according to start, limit, substring, regex

Since we now process branches iteratively, and to maintain the same
ordering, we now perform the ordering on the initial input list of all
branches. This is same since (sort then filter) is equivalent to
(filter then sort).

Google-Bug-Id: b/288895555
Release-Notes: skip
Change-Id: I2016e5c205a6daf2d4d87021d18ac1590eb685bc