Think about to interpreter API design for checksigfromstack

So, to handle the existing checksigs we have the user pass in a closure. There were two reasons for this
* To check normal signatures you need to compute a sighash, which is hard to do from the interpreter
* I wanted to be able to interpret miniscripts without checking the signatrues, since this is really expensive and doesn't give you much value if you're checking things that are in the chain anyway

I have a couple thoughts about how we could handle this here
* Not check the signature and offer no way to do so (this seems like a bad idea)
* Make the user pass a second closure in for this (ughh)
* Adapt the existing closure to take a message hash (ugly, doesn't really match the existing closure signature)
* Replace the existing closure with an optional secp context argument (but then how can we compute the sighash for normal checksigs?)
* Require our signatures to have R = P = 1, and then we can verify the signature with :P

None of these are really clean, but I'm leaning toward adding a second closure to the API.

_Originally posted by @apoelstra in https://github.com/sanket1729/elements-miniscript/pull/4#discussion_r584986887_

Beginne mit dem Einstiegspunkt checksigfromstack und der bestehenden closure-basierten Signaturverarbeitung, die im Issue beschrieben ist. Lies die Diskussion im verknüpften Pull Request, vergleiche die aufgeführten API-Optionen und bestätige, dass das gewählte Design sowohl normale Signatur-sighashes als auch die miniscript-Interpretation ohne unnötige Prüfungen verarbeitet; abgeschlossen ist die Aufgabe, wenn die API-Richtung vereinbart und dokumentiert oder implementiert ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.