Foreign key graph improvements

1)
Our foreign key graph/cache was mainly used for tracking relation access to quickly decide some actions when doing performance critical things (e.g to decide switching to sequential execution while executing a query/DML).

However, we actually don't invalidate foreign key graph for all cases that we should indeed do. This was because, most of the time we were okey with such implications that might be caused by outdated foreign key graph.

One recent issue that we hit is https://github.com/citusdata/citus/issues/4627.
For 10.0, we will workaround this issue by invalidating foreign key graph for `DROP FOREIGN KEY` commands in https://github.com/citusdata/citus/pull/4674 but this is still not sufficient.

In https://github.com/citusdata/citus/pull/4453, we attempted to improve the coverage of foreign key invalidation mechanism.
But then, we introduced `ConstraintDropped` flag and maybe we can directly use that flag to decide invalidating foreign key graph for `DROP x` commands, where `x` can be anything (like constraint, table, schema) that might somehow drop a constraint so that many changes in https://github.com/citusdata/citus/pull/4453 might not be needed at all.

However, we will still need to handle commands defining foreign keys separately.

2)
Other problem with foreign key graph is that it might actually be invalidated by another backend when we are operating on it. Probably we should have some mechanism to check if entries in graph is healthy or not (like we do for other objects that we store in `CacheMemoryContext`)