RzArch and plugins

[wargio]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository
• I made sure to follow the project's coding style
• I've documented or updated the documentation of every function and struct this PR changes. If not so I've explained why.
• I've added tests that prove my fix is effective or that my feature works (if possible)
• I've updated the rizin book with the relevant information (if needed)

Detailed description

Initial proposal and conversion of all the RzAsm/RzAnalysis plugins towards the unified RzArch* structures

Partially addresses #4334

[XVilka]

One big thing is missing in here - a target description, e.g.

typedef struct {
    char *arch;
    char *cpu;
    ut16 bits;
} RzArchTarget;

This is where we can pack also the "features", e.g. particular ISA features or anything like that. Maybe also have a separate address_width member, e.g. see function rz_analysis_get_address_bits()

[XVilka]

Is it a plugin-specific configuration?

[Rot127]

Added quite some stuff which probably shouldn't be done in the first implementation.
I think necessary is though:

• The RzArchPacket/RzArchInsn distinction.
• Starting enums always with invalid = 0 to prevent false positives.

[Rot127]

An can_xcode_transform would be nice. To test if the plugin supports a given in/out combination. Because can_xcode_in() && can_xcode_out() == true but context_xcode(in, out) could be unsupported.

[wargio]

i don't think this is an issue because we can define the transform, for example:
asm > details could become internally (in rzarch not plugins) asm > bytes > details.

[Rot127]

If we allow to query for specific properties via xcode(), we should implement also a common buffer mechanism for disassembled instructions of a plugin.
So the plugin doesn't need to disassemble everything again and again, just because the code asks for call refs, stack refs, asm_text in a row.