token invalidation outside of a single lib core ims context is not handled

**Describe the bug**
If I have a context configuration that holds an `access_token` and/or `refresh_token` and that it gets invalidate outside of this context, then on the next getToken, as long as the token is not expired it will be returned although it's invalid.

This applies for both action and cli config

**Reproduce**
```javascript
const { Ims, getToken, invalidateToken, context } = require('.')

const config = {
client_id: "",
client_secret: "XXX",
techacct: "@techacct.adobe.com",
meta_scopes: [
"ent_dataservices_sdk"
],
ims_org_id: "@AdobeOrg",
private_key: "XXX"
}

await context.set('my-ctx', config)
const token = await getToken('my-ctx')

// await invalidateToken('my-ctx') => would delete the token in the config

// but if the token is invalidate elsewhere the token would still be in the config
// example
const ims = new Ims('prod')
await ims.invalidateToken(token, config.clientId, config.clientSecret)

const token2 = await getToken('my-ctx') // would return the same cached token which is invalid
// furthermore now a call to invalidateToken will throw an error as the token is not valid
```

**Possible solution**
in every `getTokenIfValid` call in `token-helper.js` validate the token against IMS, however this will trigger many more requests and reduces the advantage of caching the token