Allow multiple delegates.

[arik-so]

This PR modifies server behavior to return the content of the first delegate it finds, absent which it returns the inscription's own content.

[arik-so]

I'm really worried about this being a DoS vector. It would be fairly trivial to inscribe something with a couple thousand non-existent delegates. Any thoughts on whether it's a) a non-issue, b) makes the multi-delegate approach altogether unviable, or c) there are some mitigating strategies? @raphjaph

[cryptocj]

Can we add a limit number to avoid the Dos concern?
And extract a function to remove the repeat code below.

fn find_inscription<'a>(delegates: &'a [usize], index: &'a Index, max_length: usize) -> Option<&'a Inscription> {
    delegates
        .iter()
        .take(max_length)
        .find_map(|delegate| index.get_inscription_by_id(*delegate).unwrap_or(None))
}

// Usage
let inscription_override = find_inscription(inscription.delegates(), &index, max_length);

[arik-so]

Of course, the question is just what the limit should be. That's why I think @casey or @raphjaph should weigh in.

[arik-so]

This PR needs a test that, on the one hand, would allow the creation a custom inscription witness with multiple delegates, while on the other hand allowing to query the /content API endpoint.

The difficulty lies in the fact that Inscription::to_witness and InscriptionId::value are only available in ord::src, whereas TestServer is only available within ord::test. It seems like an inelegant merging of responsibilities to publicly expose the inscription-related methods, or to copy TestServer into ord::src, so if this is worth pursuing, I'm open to creative suggestions from the maintainers.