Adds ability to delete a cache entry

[cannikin]

This adds the ability to delete a cache entry by its key. This will allow you to be a little more lax in your cache key names if you know you have circumstances where you bust the cache explicitly so that it can be re-built.

Consider an example where you are caching a post by its id. You currently have no way to bust the cache when the post itself changes in some way. But if you can manually delete the cache entry when updating or deleting a post, you are good to go:

import { cache, deleteCacheKey } from 'src/lib/cache'

const post = ({ id }) => {
  return cache(`post-${id}`, () => {
    return db.post.findUnique({ where: { id } })
  })
})

const updatePost = async ({ id, input }) => {
  await deleteCacheKey(`post-${id}`)
  return db.post.update({ where: { id }, data: { input } })
})

Of course this assumes that this service is the only place where a post is updated. If not, you either need to make duplicate deleteCacheKey() calls, or come up with a key that automatically busts the cache on a post change (like incorporating the updatedAt timestamp).

The deleteCacheKey() function will return true if the key was found and deleted, otherwise it returns false.

Thanks for the suggestion @dthyresson!

Closes #7003

[dthyresson]

Perhaps an an alias (or rename) deleteCacheKey to invalidate?

See: https://github.com/n1ru4l/envelop/blob/8291991e908f1bb5c9fec1ee2e6e2486f191ee2b/packages/plugins/response-cache/src/cache.ts#L27

[cannikin]

Since both libs called the function delete (and del) I figured it was best to stay with that nomenclature. I know we talk about "invalidating the cache" but I wonder if that's the proper term to use for what we're doing...invalidation sounds like it's still around, it's just not "valid" any more. Whereas memcached and Redis really seem to delete it from memory and it's no longer available...