Feature Request: Support customizing Layer account id

## Background
The plugin currently support passing `lambdaInsightsVersion` value to control the use of Lambda Insight Platform version for [x86](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-extension-versionsx86-64.html) and [arm64](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-extension-versionsARM.html). Below is the quote to the related code.

https://github.com/awslabs/serverless-plugin-lambda-insights/blob/802f7524cfec2beb0dd59d6de445afd8fd945c17/index.js#L90-L120

## Issue
However, the code has hardcoded the layer arn account id `580247275435`, but in fact, the layers doesn't necessary be deployed on that account. For example,

[x86 - 1.0.498.0](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-extension-versionsx86-64.html#Lambda-Insights-extension-1.0.498.0)
`arn:aws:lambda:us-east-1:580247275435:layer:LambdaInsightsExtension:60`
`arn:aws:lambda:af-south-1:012438385374:layer:LambdaInsightsExtension:52`
`arn:aws:lambda:ap-southeast-7:761018874580:layer:LambdaInsightsExtension:8`
...

While `580247275435` hosts most of the regions' layer, there are multiple other accounts hosting the layer for other regions.

The current implementation limits the use of this plugin, to essentially to only support regions that are hosted by `580247275435`.

## Suggestions
As the plugin already support passing `lambdaInsightsVersion` , to allow user to implicitly choose the runtime version. I suggest adding a new attribute `lambdaInsightsLayerAccountId`, with default value being 580247275435 (for backward compability), and use it to format the layer arn in the generateLayerARN function. This way, users are expected to choose their preferred runtime version by supplying both `lambdaInsightsVersion` and `lambdaInsightsLayerAccountId`.

The other workaround is to handle the mapping internally, meaning we use a table to map `region` to `account id` according to the document. But it is less future proof, as the account id used to host the layer version might change, and we have to proactively update the mapping whenever there is a new platform version release