Token creation fixes; capture mode flag; old-style basket fixes

In summary, there should be no BC breaks in the majority of cases, but a lot of code has been touched in this release, so test before putting into production. I'll aim to fix any problems as quickly as I can. There are a number of further releases to come, attempting to pull in additions that I see forks repeatedly implementing over the years, but not making it to a PR.

---

Issue #107 Old style basket text filter

• Extended Omnipay\SagePay\Extend\Item to support productCode parameter for integrating with Sage 50 Accounts. This does not yet integrate into the XML basket, which is something that should probably be done.
• Set separate character filter for old style basket item names, compared to XML basket item names. Some characters valid in the old style basket needed to be allowed through to support Sage 50 Accounts integration.

Issue #105 Token creation not consistent

• Token creation did not work at all for the Server gateway. Now fixed.
• Both Server and Direct support the createCard() gateway method to just capture a card token or card reference. The cardReference is available in the acceptNotify handler for the Server method.
• The cardToken or cardReference can be used for authorize() or purchase() for both Server and Direct. The Direct method may still redirect the user for 3D Secure authentication. The Server method will still redirect the user to enter their CVV.
• When using a saved token by applying it to a purchase as a cardToken, it will be discarded by the gateway after use. By applying it as a cardReference the gateway will be asked to keep the token retained for future use.

Issue #104 Introduce authorize and capture modes

• Sage Pay has two main ways of authorising a payment to be captured at a later time: DEFERRED/RELEASE and AUTHORIZE/AUTHENTICATE. There are distinct differences between the two, which the Sage Pay documentation explains best. The default mode is DEFERRED/RELEASE (leaves a shadow on the account for up to around 6 days, and can be released up to 30 days, but with no guarantee once the shadow expires).
• You can switch both authorize() and capture() to the AUTHORIZE/AUTHENTICATE mode by setting useAuthenticate to true.
• You can set useAuthenticate at the gateway or message level, so a merchant site can use one method globally, or mix and match depending on needs. The mode used to capture() must match the mode used to authorize() however.
• This does not introduce any BC breaks if you do not use the useAuthenticate parameter.
• To support this, the number of statuses returned by the gateway that are considered successful, have been extended. These include REGISTERED, AUTHORISED, and a few others.

Other changes:

• The transactionReference() will now be null if there are no transaction details supplied in the response (or server request) from the gateway. Previously it would contain a partially formatted JSON string. null is consistent with core Omnipay, but may be a BC break if a site is always expecting a string.
• The messages that require a reference to an existing transaction, have been extended to support both a single JSON reference or the individual parts. Which you use will depend on how your applications stores the transaction registration (most will use the transactionReference JSON string). This should not exhibit any BC breakages.
• Some message parameters have been promoted to the gateway level. These are parameters that generally affect the operation of the gateway (e.g. authorize/capture modes) which makes it easier to set as a global parameter when Omnipay is being integrated into a framework in a generic way.
• A general tidy-up and refactoring of the code has been done, with an extended test coverage. All constants have been moved to one interface, so they are available everywhere.
• The transactionType for repeat payments will default to "C" if not overridden. Previously the default was the same as for authorize() and purchase() - "E".