fix: Improve type of configure config param

[seb-cr]

This allows IntelliSense to suggest the dependencies key (and any other existing config keys) when you are entering the config parameter.

The TMoreConfig type, which is used to track the addition of arbitrary keys to the Lambda Wrapper config object, was not constrained and so could be inferred as any.

The type of the config param therefore defaulted to Partial<TConfig> & any. This is equivalent to any, and IntelliSense cannot make suggestions about keys that may be available.

By requiring TMoreConfig to extend Partial<LambdaWrapperConfig>, we still allow any object but tell the type system about expected optional keys, so IntelliSense can suggest them.

Jira: ENG-3163

[seb-cr]

This fix solves this problem but I've discovered that it breaks the SQS queue name type in SQSService. Need to find an alternative solution, and I'll also look at adding some tests for types so that we can find out immediately if we accidentally break an indirectly related type.

[seb-cr]

I finally tracked this back to a difference in how IntelliSense handles TS and JS files. In TS files, this bug does not exist.

// test.ts
import lambdaWrapper from '@comicrelief/lambda-wrapper'

const lw = lambdaWrapper.configure({})
// IntelliSense says:
// configure<unknown>(config: Partial<LambdaWrapperConfig & WithSQSServiceConfig>): LambdaWrapper<LambdaWrapperConfig & WithSQSServiceConfig>

config has the correct type and IntelliSense will suggest the dependencies and sqs keys.

But if you rename the file to .js, suddenly the type changes to any:

// test.js
import lambdaWrapper from '@comicrelief/lambda-wrapper'

const lw = lambdaWrapper.configure({})
// IntelliSense says:
// configure<any>(config: any): LambdaWrapper<any>

So, I do not believe this is a bug in Lambda Wrapper, after all!

Closing this PR.