idl: Check ambiguous discriminators

[acheroncrypto]

Problem

The ability to set custom discriminators means the user can also set discriminators that are ambiguous. For example:

#[account(discriminator = 1)]
pub struct SomeAccount {
    pub a: u8,
    pub b: u16,
    pub c: u32,
}

#[account(discriminator = [1, 2, 3, 4])]
pub struct AnotherAccount {
    pub a: u32,
}

In this example, there is no way to reliably decide the expected account type from a given account info's data. For this reason, Anchor should not allow compilation of this program.

However, this results in another problem — definitions of accounts, events, and instructions don't have access to other definitions' discriminators, as proc-macros are stateless. To solve this, ambiguous discriminators should be checked during the IDL generation process, since we have access to all discriminator values (and introducing another idl-build-like feature just to check discriminators would increase the already long build times even more).

Summary of changes

Check potential discriminator collisisons during the IDL generation step.

---

Note: This PR is part of a greater effort explained in #3097.

[vercel]

@acheroncrypto is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.