Improvement: Add support for 16bit constant from two ascii chars

[furious]

Minor changes to add support for 16bit values made of two chars, eg.: lda.w #'AS' : sta $00 : lda.w #'AR' : sta $02

[coveralls]

Coverage decreased (-0.05%) to 81.805% when pulling fec216173c38e9e203a83523a53a06f19d329af4 on furious:feature/16bit-ascii-chars into 99d1b729cca874752d1b109314d01343cb754c95 on RPGHacker:master.

[Alcaro]

'a' = $1234
'b' = $5678
dw 'a','b'

yields, with the current Asar, 34 12 78 56.

What do you propose would be the correct output for the following snippets, and is that the actual output of this PR?

'a' = $1234
'b' = $5678
dw 'ab'

'a' = $12
'b' = $34
'c' = $56
dl 'abc'

[furious]

The purpose is just for opcodes, not to change ascii table. I was disassembling a firmware that checks strings in specific locations, eg.:

; checking for "SUPERUFO" at 808000
org $808000:
    db "SUPERUFO"
...
    lda.l $808000
    cmp.w #$5355 ; when loading as 16 bit, it flip bytes to 'US' instead of the actual readable text 'SU'
    bne .not_superufo
    lda.l $808002
    cmp.w #$5045 ; 'EP' > 'PE'
    bne .not_superufo
    lda.l $808004
    cmp.w #$5255 ; 'UR' > 'RU'
    bne .not_superufo
    lda.l $808006
    cmp.w #$464F ; 'OF' > 'FO'
    bne .not_superufo

Currently, Asar only supports single char constant conversion lda.b #'A'. My intention of this PR is to make it also support 16 bit constants made from chars/text...

I was manually writing the opcode with the inverse char order, eg.:

db $C9, "US" ; = cmp.w #$5355

[furious]

Sorry, I was wrong, that piece of code I showed was written with the bytes actually flipped, so I just pushed a correction...

Here's a real example of this feature: In this code, it checks for a specific header string above

[p4plus2]

I don't really know how I feel about this one. Maybe this is better as a builtin function (say be for big endian) so it can be used in any math context. be($1234) or be("US") could then be supported for example.

I'm open to other suggestions too, but I'd rather not add a context sensitive hack. A be function could hypothetically support strings larger too, up to four bytes. Thus would work with d[bwld] (though db its effectively a noop)