Noticed these bits in a PR I'm reviewing. Might as well fix them now.

Avoids more Triple->string->Triple round trip. This
is a continuation of f137c3d592e96330e450a8fd63ef7e8877fc1908

After changes in https://github.com/llvm/llvm-project/pull/145793.

/home/david.spickett/llvm-project/lldb/source/Plugins/Disassembler/LLVMC/DisassemblerLLVMC.cpp:1360:49: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned int')
 1360 |   status = m_disasm_up->getInstruction(mc_inst, size, data, pc, llvm::nulls());
      |                                                 ^~~~
/home/david.spickett/llvm-project/llvm/include/llvm/MC/MCDisassembler/MCDisassembler.h:135:64: note: passing argument to parameter 'Size' here
  135 |   virtual DecodeStatus getInstruction(MCInst &Instr, uint64_t &Size,
      |                                                                ^
1 error generated.

The type used in the LLVM method we call is uin64_t so use that instead.
It's overkill for what it is, but that's a separate issue if anyone cares.

Also removed the unused form of GetMCInst.

LLDB uses the LLVM disassembler to determine the size of instructions and
to do the actual disassembly. Currently, if the LLVM disassembler can't
disassemble an instruction, LLDB will ignore the instruction size, assume
the instruction size is the minimum size for that device, print no useful
opcode, and print nothing for the instruction.

This patch changes this behavior to separate the instruction size and
"can't disassemble". If the LLVM disassembler knows the size, but can't
dissasemble the instruction, LLDB will use that size. It will print out
the opcode, and will print "<unknown>" for the instruction. This is much
more useful to both a user and a script.

The impetus behind this change is to clean up RISC-V disassembly when
the LLVM disassembler doesn't understand all of the instructions.
RISC-V supports proprietary extensions, where the TD files don't know
about certain instructions, and the disassembler can't disassemble them.
Internal users want to be able to disassemble these instructions.

With llvm-objdump, the solution is to pipe the output of the disassembly
through a filter program. This patch modifies LLDB's disassembly to look
more like llvm-objdump's, and includes an example python script that adds
a command "fdis" that will disassemble, then pipe the output through a
specified filter program. This has been tested with crustfilt, a sample
filter located at https://github.com/quic/crustfilt .

Changes in this PR:
- Decouple "can't disassemble" with "instruction size".
  DisassemblerLLVMC::MCDisasmInstance::GetMCInst now returns a bool for
    valid disassembly, and has the size as an out paramter.
  Use the size even if the disassembly is invalid.
  Disassemble if disassemby is valid.

- Always print out the opcode when -b is specified.
  Previously it wouldn't print out the opcode if it couldn't disassemble.

- Print out RISC-V opcodes the way llvm-objdump does.
  Code for the new Opcode Type eType16_32Tuples by Jason Molenda.

- Print <unknown> for instructions that can't be disassembled, matching
  llvm-objdump, instead of printing nothing.

- Update max riscv32 and riscv64 instruction size to 8.

- Add example "fdis" command script.

- Added disassembly byte test for x86 with known and unknown instructions.
- Added disassembly byte test for riscv32 with known and unknown instructions,
  with and without filtering.
- Added test from Jason Molenda to RISC-V disassembly unit tests.

This commit introduces a new log channel for the disassembler in LLDB,
allowing for better logging of disassembler related activities. The
`LLDBLOG` enum has been updated to include the `Disassembler` channel,
and the relevant logging in the `DisassemblerLLVMC` plugin has been
modified to utilize this new channel. This is in preparation for adding
additional disassembler implementations.

Key Changes:
- Added `Disassembler` to the `LLDBLog` enum.
- Updated logging in `DisassemblerLLVMC.cpp` to use the new
`Disassembler` log channel.

We need to iterate through the all symbol context ranges returned by
(since #126505) SymbolContext::GetAddressRange. This also includes a fix
to print the function offsets as signed values.

I've also wanted to check that the addresses which are in the middle of
the function do *not* resolve to the function, but that's not entirely
the case right now. This appears to be a separate issue though, so I've
just left a TODO for now.

Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private so the
Target class can access it, but everyone else now uses accessor
functions. This allows us to control the resolving of addresses and will
allow for functionality in LLDB which can lazily resolve addresses in
JIT plug-ins with a future patch.

Add the ability to override the disassembly CPU and CPU features through
a target setting (`target.disassembly-cpu` and
`target.disassembly-features`) and a `disassemble` command option
(`--cpu` and `--features`).

This is especially relevant for architectures like RISC-V which relies
heavily on CPU extensions.

The majority of this patch is plumbing the options through. I recommend
looking at DisassemblerLLVMC and the test for the observable change in
behavior.

We got a bug report that the disassember output was not relocated (i.e.
a load address) for a core file (like it is for a live process). It
turns out this behavior it depends on whether the instructions were read
from an executable file or from process memory (a core file will not
typically contain the memory image for segments backed by an executable
file).

It's unclear whether this behavior is intentional, or if it was just
trying to handle the case where we're dissassembling a module without a
process, but I think it's undesirable. What makes it particularly
confusing is that the instruction addresses are relocated in this case
(unlike the when we don't have a process), so with large files and
adresses it gets very hard to see whether the relocation has been
applied or not.

This patch removes the data_from_file check so that the instruction is
relocated regardless of where it was read from. It will still not get
relocated for the raw module use case, as those can't be relocated
anywhere as they don't have a load address.