refactor CDP componentry out of monorepo

[mollykarcher]

What problem does your feature solve?

We'd like to expand the scope of responsibility for our external SDK developers that receive infrastructure grants, to include the ability to interact with a galexie-exported data lake. As a precursor to this, we'd like to have a clear, concise example that they can model their implementations after in golang.

What would you like to see?

• Design/spike to determine which libraries/components should be moved out into a separate repository, and which should stay
• Work to refactor said components out of the go monorepo and into their own repository
• Documentation in the public developer docs advising developers as to how to use new repo

Considerations

• Note that the ingest library includes a lot of code that handles the lifecycle of captive core and makes the interface to it look the same as that to the data lake. For external providers, we won't be asking them to build code that interfaces with captive-core directly
• Consider that we eventually will want to facilitate open source contributions of other data stores (S3, R2, etc). Awareness of this may influence overall design and choice of where the interfaces live

[mollykarcher]

Per discussion at planning meeting on 11/12, we will explicitly scope this down to just the BufferedStorageBackend. So just wrapping of a gcs client, downloading/buffering ledgers, and outputting a LCM object.