Replace R_LARCH_SOP_PUSH_* with regular bit extraction relocation types

[MaskRay]

Per @xen0n on #3 (comment)

Plus it seems there's a stack machine implemented with relocation records. I think this is bad for these reasons:

Fragility could ensue due to tools not respecting relative order of relocation records on the same address;
It's superficial, conveying actions and not motivations, which is generally bad smell in software engineering;
Not much complexity is shed by the introduction of intended flexibility here, so it wasn't exactly profitable either;
No prior cases wheresoever found in public code, so it's not sure if the scheme is to be appreciated universally.
I suggest removing these if possible; at the very least, continue to support this model if you MUST support the already existing early LA world with the upstreamed toolchains, but stop generating these in the future; define distinct relocation types for all the macros utilizing computation in their expansions, just like any other architecture.

As a replacement, some new relocation types with fixed bit extraction and shift can be used.

• The stack machine requires considerable complexity in the assembler. Assemblers use sym_a-sym-b+const to represent a value. It is difficult to represent shifts on a symbolic operand.
• The stack operating relocations waste space in relocatable object files.
• The stack machine is not clear what parallel relocation resolving should do.
• Various assembly producers need to deal with the complexity of a plethora of stack operating relocations.

[ChenghuaXu]

Hi, The new reloc type #57 has been merged, Plz close this.