Improve explanations of core architecture

[KyleAMathews]

From conversations on Discord, it seems like most people come to Electric assuming we always store data in indexeddb or that you have to have a client-side db like pglite. Which makes sense! As that's how a) Electric used to work and b) how many other sync/real-time tools work.

We should do a pass on the doc to see how / where we can more clearly describe how Electric works — that it's several modular components (electric server, sync protocol, typescript client, pglite, etc.) that optionally can work together (or not!). And the scenarios under which you need a client cache/db or not.

Here's a comment I made during a discussion earlier on Discord:

just to make sure we're on the same page — electric doesn't store data in indexeddb like Zero does — we don't have an actively managed client cache where you'd need to manually "clear old ones".

Because Electric works over http instead of websockets, we use a built-in cache — namely the browser's HTTP cache.

Best way to see this is to play with the various examples while looking at the network tab — see what their cache-control settings are. Refresh the page to see that old shapes get loaded from the local http cache.

So generally you don't need to think very much about this — you just load shapes that are needed for different routes and things are either pulled from the cache or they're loaded fresh.

It works exactly like using tanstack/query or something except with a sync primitive instead of a fetch primitive.