Added custom CheckType & clarified panic behavior in docs

[abelmarnk]

###Summary of Changes

Two changes are added:-

##Custom Check Support

It allows for custom program checks to be added to the regular check flow

• Added a new Custom variant to the CheckType enum.

• Added a corresponding helper (Check::custom) that allows to provide a custom validation function alongside a descriptive name.

• Extended the check handler logic to handle the new Custom case, allowing user-supplied functions to be invoked during validation just like the built-in checks.

##Documentation Updates on Panic Behavior

Updated documentation for process_and_validate_instruction and process_and_validate_instruction_chain.

• Clarified that checks panic by default, but this behavior is configurable through Mollusk::config.

[buffalojoec]

Cool, thanks!

Just for some context, do you have an example of how you might use this check, and how that wouldn't be something available through the Check::account check API?

[abelmarnk]

Clarified:-
The main case in mind is that the account check is able to test the contents of an account after an instruction in a series of instructions, but it cannot perform checks that require the resulting state of several accounts simultaneously after the particular instruction has been run, an example would be an AMM, where the amounts in the vaults after a swap would all be tested to together to satisfy some equation, which would result after a swap or similar instruction in a series of instructions has just been run.

[buffalojoec]

Clarified:- The main case in mind is that the account check is able to test the contents of an account after an instruction in a series of instructions, but it cannot perform checks that require the resulting state of several accounts simultaneously after the particular instruction has been run, an example would be an AMM, where the amounts in the vaults after a swap would all be tested to together to satisfy some equation, which would result after a swap or similar instruction in a series of instructions has just been run.

I think for a situation like this, you actually want to just access the returned InstructionResult directly. It has its own API for retrieving resulting accounts and you can just use assert!/assert_eq! on the data, or use result.run_checks.

I'm worried that getting into the weeds here on generic checks might set a bad precedent for the API's development. It's really hard to try to write a good generic check parameter like this that's expansive enough to cover all of the edge cases someone might have. In fact, that's exactly what the API on the InstructionResult was for in the first place.