Use ld_hli_a_string macro to make byte-by-byte strings more obvious

[Rangi42]

Fixes #539

[Rangi42]

This is another macro like dbit that Gen 2 doesn't use often enough to be worth factoring out, if at all. (I only see the bold "VS" in pokecrystal.) Edit: git grep -niE "ld (a|b|c|d|e|\[hl\]), '[a-z]'" can help find possibilities too.

[vulcandth]

Using macros to output data tables is one thing; but I'm not entirely sure how I feel about outputting multiple instructions (code) using a macro in the main repos. So far the most we've done for code output in the main repos list this is things like farcall and the lb macros? Unless i'm wrong.

Mainly cause it obscures the code itself.. Would definitely use it in a hack though!

Anyways not saying no, just wanted to see your thoughts on that, oh and dannye's thoughts too! :)

[Narishma-gb]

So far the most we've done for code output in the main repos list this is things like farcall and the lb macros?

In Gen 1, macro/events.asm does output a lot of code, with multiple IF conditions.

[vulcandth]

So far the most we've done for code output in the main repos list this is things like farcall and the lb macros?

In Gen 1, macro/events.asm does output a lot of code, with multiple IF conditions.

I stand corrected.

[Rangi42]

macros/code.asm is where we keep other such macros, including dict (which Gen 1 uses somewhere else besides home/text.asm), maskbits (not yet ported to Gen 1, and ideally would be a user-defined function like ld a, maskbits(NUM_THINGS)), jumptable, calc_sine_wave (only because it's repeated so many times), etc.

[Rangi42]

Mainly cause it obscures the code itself.

Yes, but I think un-obscuring the string values is worth that cost.

[dannye]

I like it a lot 👍