program-error: Add option to specify solana_program crate

[joncinque]

Problem

There are going to be a lot of issues with people seeing errors on
spl_program_error derivation. When a build pulls in two version of
solana_program, the macro uses ::solana_program, which now becomes
ambiguous.

Summary of changes

I'm not sure if this is a good idea, but this PR gives the ability
to specify which version of solana_program to use when deriving the
various traits on your error type.

Borsh has this same functionality, and it's saved us when pulling in
multiple versions of borsh in the SDK.

Note: this PR defaults to solana_program instead of
::solana_program, which might cause downstream issues.

[buffalojoec]

Ahh clever, this could be useful. num-derive also lets you do this with num-traits, but it looks like it defaults to expecting the dependency to be in the crate's manifest.

https://github.com/rust-num/num-derive/blob/7cc33515dd2ae0eb43c5795c50ce49c554e8ba02/src/lib.rs#L152

However, they make use of a clever little trick - documented as being plucked from serde - to register the user's import as a local _num_traits module.

https://github.com/rust-num/num-derive/blob/7cc33515dd2ae0eb43c5795c50ce49c554e8ba02/src/lib.rs#L184-L191

Maybe we can do it this way for the default? I think that should avoid the ambiguous glob problem from #6590. What do you think?

[buffalojoec]

Additionally, now that I'm looking through the num-traits macro attribute, we could also maybe offer that as a passthrough arg so that we're not blocking access to the #[num-traits] attribute for downstream users, since we're leveraging it for each derive.

solana-program-library/libraries/program-error/derive/src/macro_impl.rs

Line 138 in 97c0400

#[num_traits = "num_traits"]

[joncinque]

Thanks for the feedback! Let me know how this looks.

Additionally, now that I'm looking through the num-traits macro attribute, we could also maybe offer that as a passthrough arg so that we're not blocking access to the #[num-traits] attribute for downstream users, since we're leveraging it for each derive.

Definitely makes sense, but I'd prefer to keep that for future work if that's ok with you

[buffalojoec]

This looks great! I think this will help with dependencies a lot. Thanks!