Control which framework/technology transactions are created from

**The problem**
I am hosting fastify APIs in AWS Lambda functions, using API Gateway as a proxy to route requests to the lambda. I am using [fastify/aws-lambda-fastify](https://github.com/fastify/aws-lambda-fastify) to do this.

In a non-Lambda context, when I start the APM agent, it will hook in to the fastify context and create transactions based on routes that are hit. For instance, if a user navigate to

```
GET /users/3ffb7b9c-655e-4a87-b094-8eea9c725d0d/profile
GET /users/3ffb7b9c-655e-4a87-b094-8eea9c725d0d/roles
DELETE /users/3ffb7b9c-655e-4a87-b094-8eea9c725d0d
```

then the resulting transactions would be based on the registered route configuration to group related requests, so it would end up in APM something like this:

```
GET /users/:userId/profile
GET /users/:userId/roles
DELETE /users/:userId
```

The problem is when I use the Elastic APM agent on fastify APIs hosted in Lambda functions as described, the transaction is based on the API Gateway context. Given that I am proxying all traffic from API Gateway the examples above will show up as:

```
GET /users/{proxy+}
GET /users/{proxy+}
DELETE /users/{proxy+}
```

Of course this grouping is not desirable, as it only really separates routes by HTTP method and not by the URL.

**Suggested solution**
I would like some setting to control which technology/framework to base transactions on. As far as I can tell I have no way to do this now. In my case I would want APM to use fastify instead of AWS Lambda/API Gateway. It could possibly look something like this:

```
// On the agent:
apm.usePreferredFramework("fastify") // "awslambda" | "fastify" | "nextjs" | "azurefunction" | ...

// Or as an environment variable:
ELASTIC_APM_USE_PREFERRED_FRAMEWORK=fastify
```

**Alternatives**
I have looked into [`usePathAsTransactionName`](https://www.elastic.co/guide/en/apm/agent/nodejs/current/configuration.html#use-path-as-transaction-name), but that setting eliminates all grouping so this is not desirable either. Having looked through the documentation I have not been able to find a suitable workaround.