Fix #4974 - Print binary Cd data in value order ##disasm - #27348

• Mark this if you consider it ready to merge
• I've added tests (optional)
• I wrote some lines in the book (optional)

Description

Fixes #4974. With a binary immbase (ahi 1), a Cd data item printed its bits in memory order, while every other base prints the value read with the configured endianness. A little endian dword 03 00 00 00 showed as 00000011000000000000000000000000b, so ? on that text, as in the issue, gave a different number, and e cfg.bigendian made no difference.

data_type_tostring now writes the value most significant byte first before printing the bits, so the binary text is the same value as the hex and decimal text, and cfg.bigendian changes it the way it changes hex.

When the value fits the directive, the text now assembles back to the same bytes (rasm2 round-trips .int16, .int32 and .int64 with a b suffix on x86, arm and mips). So data_type_assembles treats binary like decimal: pdj puts it in opcode, and keeps .hex there for a single byte or a 16/32-bit value above the signed maximum. This drops the "binary digits follow memory order" exception from #27320.

Something I left alone: for Cd data, immbase 1 is binary and 2 falls back to hex, while for instructions ahi s (1) is string and ahi b (2) is binary, as ahi? says. So ahi b on a Cd item prints hex. I can change that here or in a separate PR if you want.

Testing

• New test in test/db/cmd/metadata: the same dword printed with both endiannesses.
• Extended the cmd_pdj Cd test with a dword that has the top bit set (.hex in opcode, binary in disasm) and a word (binary in opcode).
• Updated the expected binary output in three existing tests (two in metadata, one in cmd_pdj).
• The changed tests fail on master. db/cmd/metadata (231), db/cmd/cmd_pdj (178), db/cmd/cmd_ahi and db/cmd/cmd_pd pass. sys/lint.py --all is clean.