Refactor absorb_weight and use leftorth in _qr_bond

[Yue-Zhengyuan]

This PR refactors the function absorb_weight and replace the direction labels t, r, b, l (borrowed from YASTN) with the existing constants NORTH = 1, etc.

In addition, in _qr_bond for time evolution, I found that using leftorth only appears to be more numerically stable for some reason. So I want to make this change as well. Another possible advantage is that using leftorth only can help produce a bondenv around a, b that is a linear map between "un-dualed" spaces, which can save some twists:

    ┌-----------------------┐
    |   ┌----┐              |
    └---|    |-← a === b →--┘
        |benv|   ↓     ↓
    ┌---|    |-→ a† == b† ←-┐
    |   └----┘              |
    └-----------------------┘

[codecov]

Codecov Report

Attention: Patch coverage is 97.95918% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/states/infiniteweightpeps.jl	97.22%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/algorithms/time_evolution/evoltools.jl	100.00% <100.00%> (ø)
src/algorithms/time_evolution/simpleupdate.jl	86.84% <100.00%> (-0.18%)	⬇️
src/states/infiniteweightpeps.jl	90.00% <97.22%> (-1.36%)	⬇️

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lkdvos]

Thanks for the changes, looks more or less good to me. I don't really understand how leftorth and rightorth can behave that differently, unless we really are missing a twist somewhere, which is definitely possible.

I left some comments with suggested alterations, but feel free to give your opinion about them too, this is definitely not a requirement or anything.

[Yue-Zhengyuan]

I found the issue with rightorth when performing FU with an initialization obtained earlier with only leftorth. If I continue the evolution with leftorth only, the energy change log is

step      dt   doping    e_site          Δe       |Δλ|  speed/meas(s)
1      1e-02   0.0252  -7.39936         NaN        NaN  241.480/734.391
10     1e-02   0.0252  -7.39936  -9.835e-07  4.210e-06  130.743/626.449
20     1e-02   0.0252  -7.39937  -1.001e-06  4.244e-06  137.741/655.694
30     1e-02   0.0251  -7.39937  -1.004e-06  4.219e-06  132.872/651.762

If I use both leftorth and rightorth, the energy change log is almost the same:

step      dt   doping    e_site          Δe       |Δλ|  speed/meas(s)
1      1e-02   0.0252  -7.39936         NaN        NaN  286.213/663.429
10     1e-02   0.0252  -7.39936  -9.835e-07  4.210e-06  174.856/509.017
20     1e-02   0.0252  -7.39937  -1.002e-06  4.242e-06  181.070/538.702
30     1e-02   0.0251  -7.39937  -1.004e-06  4.220e-06  182.025/565.015

(ignore the speed difference; variables are not controlled)
However, I get lots of warnings during the ALS optimization step when using rightorth, which is absent when using only leftorth:

┌ Warning: GMRES linsolve stopped without converging after 100 iterations:
│ * norm of residual = 1.43e-08
│ * number of operations = 2902
└ @ KrylovKit ~/.julia/packages/KrylovKit/i0JjG/src/linsolve/gmres.jl:123
┌ Warning: GMRES linsolve stopped without converging after 100 iterations:
│ * norm of residual = 1.56e-08
│ * number of operations = 2902
└ @ KrylovKit ~/.julia/packages/KrylovKit/i0JjG/src/linsolve/gmres.jl:123
┌ Warning: GMRES linsolve stopped without converging after 100 iterations:
│ * norm of residual = 7.73e-10
│ * number of operations = 2902
└ @ KrylovKit ~/.julia/packages/KrylovKit/i0JjG/src/linsolve/gmres.jl:123

# and a lot more...

It may be because the initialization is obtained using only leftorth, which is in a different "gauge" that somehow does not work well with rightorth, but frankly I don't fully understand why this happens either. Nevertheless, I guess the save on some twists during bond truncation is a good enough reason for me to use leftorth only.

[lkdvos]

This really seems to indicate that we are missing some twists somewhere though, because otherwise there is no other difference of gauge: rightorth really is defined in terms of leftorth (see here), so the only difference can be the arrows.
I'm okay with keeping it as leftorth for now, but at some point we should really investigate this a bit more.

[lkdvos]

Ok to go for me if positive reply on my last comment.