Lay out a plan for short- and long-term catalog access

[johannct]

While this possible, the implementation would look quite ugly unless we go change the underlying composite catalog code. But before we further expand GCR's functionality, we should really ask if we should instead explore using database instead.

Originally posted by @yymao in https://github.com/LSSTDESC/gcr-catalogs/pull/393#issuecomment-539975714

I would like to use this issue to jump start a serious discussion about Yao's concern above : more and more people are using GCR, patching it when need calls for it, and in the process become quite used to it, while it by no means was intended to serve a released LSST or DESC catalog access general and complete usage. Even if the final project data access choice is not made yet, we likely can investigate toy DB access and putting up a path forward to either GCR incremental upgrade or complete rewrite. The user base has grown within DESC so that I believe that we have a good set of use cases at hand to fuel the brainstorming. Of course I will first defer to the opinion of the main stakeholders : @yymao and @wmwv

[johannct]

@yymao's prioritization plan : https://docs.google.com/document/d/1l0gIO4YKE6uouiylX_nLa-a0hwGUTggTOwEON1IqEb8/edit?usp=sharing As of yesterday's meeting we should use the same doc to ping the users for pluses and minuses of the current GCR implementation, and features request (possibly a list of open github issues)

[yymao]

Here's an updated GCR Prioritization Plan written by Yao-Yuan Mao, Joanne Bogart, Johann Cohen-Tanugi during the 2020 January collaboration meeting.