10: support linking with lld r=dvc94ch a=danc86

Rust now ships an embedded copy of lld, so if we can link crates with lld it will make the getting started experience way smoother (don't need to find a separate GNU ld).

Co-authored-by: Dan Callaghan <djc@djc.id.au>

To work around a bug in lld, we need to avoid starting the .bss section
from a fixed address (previously, the _sbss symbol). Otherwise lld
incorrectly tries to extend the FLASH output region up to the start of
the RAM output region, which is too large.

To work around another bug in lld, we need to avoid starting sections
marked with (INFO) from a specific starting address. Its parser does not
accept both a start address and the (INFO) attribute.

Specifying these start addresses is redundant anyway, the linker will
lay them out in sequential order for us.

The .cfi_* assembler directives cause call frame information to be
emitted in a special .eh_frame section. But this is not needed in the
final binary, because we are not doing panic unwinding.

GNU ld already discards this section with its (default) --gc-sections
behaviour. Lld doesn't do that by default though, instead it complains:

    rust-lld: error: no memory region specified for section '.eh_frame'

So let's explicitly discard the .eh_frame section.

This aligns the VMA (virtual adddress at runtime):

    .rodata ALIGN(4) :
    {
        ...

whereas this aligns the LMA (load address):

    .rodata : ALIGN(4)
    {
        ...

If we ensure the VMA is aligned the linker will keep the corresponding
LMA in sync (and it will be aligned too).

Previously, by forcing the LMA to be aligned but leaving the VMA
unspecified, the linker would split .text and .rodata into two
separate loads because their addresses fell out of sync.

This is no longer necessary now that we can configure the target to
exclude the .debug_gdb_scripts section.
See: https://github.com/rust-lang/rust/pull/53139

This is needed for lld, otherwise it will complain about section flag
mismatch:

    ld.lld: error: incompatible section flags for .text
    >>> target/riscv32imac-unknown-none/debug/deps/libriscv_rt-7850ee1a6233fbe9.rlib(riscv_rt-7850ee1a6233fbe9.4tmuw4s4crjeqbm5.rcgu.o):(.trap): 0x4
    >>> output section .text: 0x6

Matches cortex-m-rt. See:

https://github.com/rust-embedded/cortex-m-rt/pull/69
https://github.com/rust-embedded/cortex-m-rt/pull/78

The #[naked] attribute means Rust won't emit instructions to push and
pop a new stack frame. But the assembly routine which calls _start_rust
also doesn't push a new stack frame, so there is no valid stack for this
function.

We probably need a stack frame though, since it's implemented in Rust
and we can't easily ensure that Rust won't try to allocate any local
variables. See #5.

I'm not sure when this changed, but without this patch the app does not
seem to run, and with it the blinky_delay test app works as expected.

This is also how it looks in cortex-m-rt:
https://github.com/rust-embedded/cortex-m-rt/blob/6c269f195c9a705162fd912beb952b430cc28336/src/lib.rs#L468

In the original riscv-rust fork the target arch was simply named
"riscv", but RISC-V support landed in Rust with "riscv32" as the arch
name instead.

Include "riscv64" optimistically for future-proofing.

This reverts commit 030c12f3.