[BIP-119] Slim down motivation, add more references

[JeremyRubin]

The level of detail in the motivations for BIP-119 was excessive, this PR removes the lengthy motivation section and adds more links out to various resources.

[ghost]

ACK de0ff36

This would make it easier for developers to review the BIP and not get confused with the use cases. 2 suggestions that can be ignored.

[bucko13]

ACK. Just a couple of small copy edit nits.

[AdamISZ]

ACK for this simplification, the very large detailing of application constructs seemed not appropriate for this type of doc.

Having said that, it may be overkill to give only names and leave everything else to citations; short summaries in-text of a few major applications are common (off the top of my head I remember BIP65, BIP340, I'm sure there are many, many others!). But I mean, this works, as is.

(Another thing to consider is ordering: I never liked having to scroll so far down to find the Rationale section).

[JeremyRubin]

@AdamISZ I think the BIP-65 example makes me think that it may be best to err on the lighter side w.r.t. applications...

None of the given examples are particularly in common use, if at all? Where they have been used is in HTLCs, which are (IMO -- I could be misreading) very different from what is stated in the BIP.

Similarly, BIP-340 links to MuSig, which has a flaw rendering it "less usable"/unprovable.

This leads me to believe that it's better to be abstract in the applications section, as previous examples in BIPs don't fully stand the test of time, but the concepts do.

[AdamISZ]

I think that's a pretty decent overall take fwiw.

(Re: BIP340's link to the 2018/068 paper, it's no longer the flawed version there, but the patched up one, so it's not technically a mistake, but yeah for sure once the MuSig2 BIP is actually assigned they will presumably want to update it since that's significantly preferable).

[luke-jr]

IMO better to keep it all in the BIP (links die), but you're the author...