Attempt to authenticate tokens without X-Token-Type

[djones6]

This PR aims to simplify use of this plugin with third party clients that send a standard Authorization header but do not supply our custom X-token-type header.
Resolves #6

Current Credentials behavior is:

• No plugins registered: does nothing (calls next())
• One or more plugins registered: calls plugins in order, until one succeeds, fails, or they all pass (in which case an unauthorized response is sent)

The token plugins decide whether to pass or attempt authentication based on the X-token-type header:

• If X-token-type == JWT, it will attempt to authenticate the Authorization header and either succeed or fail.
• If X-token-type is a value other than JWT, it will pass (defer to other plugins).
• If X-token-type is not set, it will attempt to authenticate the Authorization header and either succeed, or pass (defer to other plugins). This is the new behavior introduced here.

It is important that it passes (rather than failing) in the case where the X-token-type is not set, as this can be considered a 'speculative' attempt which could really be intended for another plugin.

[CameronMcWilliam]

All looks good.

[djones6]

@CameronMcWilliam FYI, I realised I had not added a test for type-safe JWT middleware in the absence of the X-Token-Type header.

While adding that I discovered that the test for skipping authentication was wrong: it was actually rejecting the JWT because we hadn't set up a verifier with .unauthorized, but then the second Codable route was invoked which overwrote that response with the one the test expected.

Having two Codable routes registered to a path isn't a good idea as you could end up with multiple responses in the same body, and the last one that executes dictates the response status. So I've replaced those routes with a single route that uses TypeSafeMultiCredentials to test whether the JWT middleware passes to the next middleware (a trivial type-safe HTTP Basic middleware).