Add support for external keys and importing custom key material

[onematchfox]

This PR adds support for EXTERNAL origin keys and the ability of import custom key material.

One note of the implementation of the key material import process is that I have chosen the easy (lazy?) route of just attaching a single ParametersForImport to an existing key. This means that multiple calls to GetParametersForImport will resulting in the older parameters being overwritten. Not sure if this differs from the AWS implementation or not. However this implementation does:

• offer a simplistic way to test "expired/non-existent" import parameters as one can simply call the get parameters method twice
• simplifies the implementation and reduces database size (over time) as we don't have to worry about cleaning up expired import parameters

Also, I haven't added any tests for this yet. I have looked at the Postman collection and am open to trying to add tests to this collection even if I'm not exactly sure how to generate the required input for ImportKeyMaterial (see bash script in README.md for what this looks like). However, when I did import the Postman collection it took me quite a while to get the existing test set running as it relies on a number of variables which seem to be stored in local environment rather than as part of the collection. Might be worth considering other options - native go tests? Am open to ideas/discussion here.

[nsmithuk]

Thanks @onematchfox, I'll take a look at this asap this week.

And I agree the testing needs changing. Postman worked fine as a quick way of getting started, but it's not really conducive to multiple developers. I think perhaps it should be swapped out for something script based. I'd like to keep the tests functional based - i.e. testing from a HTTP perspective as I've built most of this with TDD; writing tests against AWS, then implementing LKMS to match. So native Go sounds a good option. Or Python with Requests perhaps.