Closes #19

proof of concept for how to expose an invalidation helper for reads. i've implemented a useInvalidateRead() hook that accepts a "path" (a unix path-like string) and relevant parameters based on the path. This will mostly be used in cases where something external to core is updated and affects core (a good example is the custom map file import).

function Screen() {
  const importFileMutation = useMutation(...)
  const invalidateRead = useInvalidateRead()
  
  return (
    <Button 
      onPress={() => { 
        importFileMutation.mutate(undefined, {
          onSuccess: () => {
            // Invalidate maps-related queries after file import
            invalidateRead('/maps', undefined)
          }
        })
        
      }}
    >Import file</Button>
  )
}

Not totally committed to the API design here. The alternative was to just export 1-to-1 mappings of functions that invalidate a specific read. After considering it for a short while I decided that:

1. Exposing a single hook that can be used as opposed to several was preferable. There's an implicit dependency on accessing a query client in order to actually do the invalidation, so exposing non-hook functions isn't an option since we don't want the usage to require explicitly passing in the query client as a param.

2. Given (1) entails exposing a single hook, having the path-like argument is super helpful as it makes it easier to visualize and understand the cascading nature of invalidations. The autocompletion support feels better than having literal string names that are mapped to each kind of read (e.g. invalidateRead('allProjects'), invalidateRead('singleProject', ...), invalidateRead('maps'), etc). If you're familiar with various router apis that support interpolated params, it's quite familiar to use.

TODO:

• finalize API
• write tests