riscv-rt: new attribute macro to define custom _setup_interrupts function.

[romancardenas]

This PR provides the following changes:

1. New custom-setup-interrupts feature to opt-out the default implementation of _setup_interrupts
2. Now, instead of defining a _default_setup_interrupts symbol that acts as a weak implementation of _default_setup_interrupts, riscv-rt now directly defines _setup_interrupts (protected under a feature gate). This reduces the amount of code in the final binary when users define their custom interrupt setup routine.
3. Now, _setup_interrupts can accept an usize input argument that corresponds to the ID of the running hart. This might be useful in multi-hart targets to define hart-specific interrupt setup routines.
4. New riscv_macros::setup_interrupts attribute macro for aiding users defining their custom interrupt setup routine.

About feature naming

I think custom-setup-interrupts is a clear name for the feature, as it should be activated whenever users want to implement their custom interrupt setup routine. However, previous similar features follow a no-* name (e.g., no-interrupts or no-exceptions). Let me know if you prefer to stick to the no-* naming or if you prefer using custom-*.

While I am currently more inclined to custom-*, I would like to know you opinion.

[romancardenas]

@MabezDev what do you think about calling the feature custom-setup-interrupts instead of no-setup-interrupts? It breaks the current naming convention, but I think it is clearer the purpose of this feature.

[thejpster]

Wouldn’t the default function be garbage collected by the linker when it observes that it’s unreachable when it’s replaced by another function?

If not, I have problems over in aarch32 land…

[romancardenas]

This full story started with #155

It looks like "default" symbols are not optimized out, and when you override them, you end up having both routines. We have been working on reducing/reusing default symbols to minimize this binary size overhead since then.

As a side note, we experimented with weak symbols in assembly (that was our first approach). However, using weak symbols currently breaks LTO (#247)