Currently, we have both `la(address)` and `la(Address)`. They accept and handle literal address.
While `la(Address)` always emit a movptr sequence, `la(address)` is not simple: it checks whether
target is reachable from anywhere within the code cache (`is_32bit_offset_from_codecache`) and
emits pc-relative auipc+addi pair or movptr sequence. This makes it not that obvious at places
where we want an accurate estimation about the size of the code emitted like when we prepare code
stubs like C2SafepointPollStub or C2EntryBarrierStub.

I would suggest we keep `la(address)` simple and let it only emit auipc+addi pair, which will be
consistent with the RISC-V Assembly Programmer's Handbook. It's more reasonable to move the distance
check to `la(Address)`. Furthermore, I would also suggest that we make the distance check simpler.
We only check whether the target is inside the code cache. Then we will be more certain about code
emitted with `la(Address)` as well. This will help keep the risk of this change low as `la(Address)`
callsites with literal address outside of code cache won't be affected. And I don't think the
original distance check from code cache will benefit us much more. Eyeballed all `la(` callsites,
seems we are fine.

Benefits:
1. We have simpler `la(address)` which is kind of spec compatible;
2. We are consistent on address check when do j(Address), la(Address), ld/st(Address) and rt_call;
3. We don't need explicit use of relocate with lambda for most of the places;

Note that there are several places where we want explicit `movptr`:
1. In `SignatureHandlerGenerator::generate()` where the emitted code is copied without relocation;
2. In `movoop` and `mov_metadata` where we want patching afterwards;