Allow disabling memoization for all requests of a client

[mairatma]

What is the purpose of this pull request?

Adding an optional flag for HttpClient to disable memoization for all requests by default.

What problem is this solving?

All HttpClient classes have memoization turned on by default, and the only way to turn it off today is by request. And even that way is not helpful for Node.js apps, because the methods provided by subclasses of HttpClient don't provide the option of passing this config anyway.

This new flag for HttpClient allows apps to configure the value for memoizable per client, which was previously true for all of them. I set the default value of this new flag to true so that there will be no behavior change at all.

The reason why we wnant to be able to turn memoization off is because we've noticed that apps like pages-graphql never get hits for those, so having it enabled is a waste of memory and of garbage collector work.

How should this be manually tested?

Link @vtex/api to a local app and try setting this new flag to false for some clients. Checking honeycomb traces will show that the setting is now disabled for each outgoing request for that client.

I've tested this on pages-graphql, for example and these are the traces:
1. Trace from master workspace, without the change - link. You can see that the http.cache.memoization.enabled field is always true for outgoing requests from pages-graphql.
2. Trace from a workspace with the change, without setting the new flag - link. You can see the same behavior as in master: the http.cache.memoization.enabled field is always true for outgoing requests from pages-graphql.
3. Trace from a workspace with the change, setting the new flag to false - link. You can see that the http.cache.memoization.enabled field is always false for outgoing requests from pages-graphql. Code for this is in this other PR.

Screenshots or example usage

Types of changes

• Bug fix (a non-breaking change which fixes an issue)
• New feature (a non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Requires change to documentation, which has been updated accordingly.

[filafb]

Just nitpicking about documentation. Since the interface is highly available for internal and external developers, it think it's worth it providing a explanation about the API it. WDYT?