performance: LRU, memoize abstraction

### Problem

1. LRU is a common mechanism re-implemented in various places, for example in dynamicResources: https://github.com/aws/aws-toolkit-vscode/blob/00bdbbe9109eb5f4b78805a92b33b31497a99e85/src/dynamicResources/model/resources.ts#L8
- These caches can be a hidden source of future bugs if they get big or have bugs. Using a common implementation provides visibility and troubleshooting through logs and inspection tooling.
3. Toolkit also has functions like `getIdeProperties()` which are called very often, and inspect deep codepaths, including external resources like vscode settings.json. The result of such functions will not (must not) change, so it is wasteful to recompute them many times. https://github.com/aws/aws-toolkit-vscode/blob/538d65b3023923215e487afd47f94804cfc9db35/src/shared/extensionUtilities.ts#L75

### Solution

Introduce a "memoize" util function or potentially a third-party library, which makes it easy to cache the result of such functions. We could make a wrapper that stores things in a global structure, then to apply it to e.g. `getIdeProperties()`, the code would rename `getIdeProperties` to `_getIdeProperties`, then `getIdeProperties` would wrap `_getIdeProperties` in a `memoize()` call.

```
function getIdeProperties() {
return memoize(_getIdeProperties())
}
```

Start by reading the cache implementation in src/dynamicResources/model/resources.ts and the frequently called getIdeProperties() entry point in src/shared/extensionUtilities.ts. Compare the existing caching patterns and determine the shared LRU/memoization scope, including how inspection and logging should work. Done means the abstraction is defined and the named use cases can adopt it without changing their results.

Written by the indexing model from the issue text.