Instant finalizations

Fix #55 and #56

This may be a breaking change from v2.2 - Instant finalizations solved, but with new configuration values. If you are running an old plugin with this in mind, make sure you check those settings.

Also solves a bunch of other problems:

• Added mock for createIframeExceptions. Turns out that paymentId is sometimes reused in a bad way, causing the plugin to shut down. If there's a payment id where Resurs Bank is protesting, the plugin now regenerates a new payment id each time we get an exception from Resurs Bank. I know we should use code 3, 8 or 404 detection here but we always regenerate payment id's at first for the moment. By enabling mocking, we can simulate such errors easy.
• So getProperPaymentId is updated with a $forceNew feature, since ecom aswell tries to reuse payment id's unless the force.
• Added support for can_log_info, meaning all mocked exceptions can now be logged except for the INFO-serverities that is already forced into the logs.
• Auto debit feature is already there, we only put it in effect where the status array needed the AUTO_DEBIT too.
• Options for methods that supports autodebits are added and status selector for them.
• Added filter setCurlTimeout.
• "Critical" Exceptions are not returning file and line when throwing exceptions (Related to RWC-258 and #56).
• Typos "desc_top" changed to "desc_tip" so now descriptions are shown as they should in wp-admin.
• Fixed a public in the mocking section (plugin).

Partial crediting orders

This is nor an actual breaking change, since the ruleset has always been quite clear: Payment providers do no support partial crediting accodring to early notes. The first plan was to actual make a warning statment of this in the plugin, but it has now been cancelled so we're leaving more responsibility to the API itself for this part.

Race conditions in order status changes

A few weeks ago (from nov 28 2021) an important case was solved that handled order status changes and the priority order where order statuses could be a fight between two different places in the plugin: If the customer lands on the landing page first and changes the order status of the order, this could affect the callback if it was later. If the callback went of before the landing page, that could affect the status too. And if both events occurs exactly the same, there would be a status update war where stock handling if the main actor to be affected where stock is in risk of been drawn twice. RWC-87 below, is one part of this that thanks to the new solution could be cancelled. If there's any need for it again, we have it kept but cancelled.