refactor: store file content in atom

[sehyod]

This PR fixes #32

This splits the state in a more atomic way, with the following:

• core primitive atoms storing simple data
• core action atoms doing simple operations
• exported combined atom holding the logic and calling the core atoms

This also adds an activePane state, that enables the app to open new file in the pane that has been used in last.

[danvk]

Nice to see the atoms wired up! Lots of suggestions but at a high level:

• Now that chore: set up frontend testing infrastructure #100 is in, this really needs some tests. It would be great to have tests for some of the invariants that you're maintaining, for example that a file gets purged from memory once it's closed in both panes. OK if it's in another PR, but it should probably the very next PR!
• I think we should use an eslint rule to enforce that "core" atoms are only used in the expected places, rather than relying on comments and underscores. See comment below.
• I believe Jotai's atomFamily is designed to eliminate some of the bookkeeping around Maps.

It's less scary to refactor once you have tests, so maybe a path forward could be to add some unit tests for src/atoms/fileActions.ts (the public state API) and then refactor the internals to use atomFamily.

[sehyod]

Thank you for these comments. I have addressed them
About the atomFamily, I decided not to use them because of this comment: pmndrs/jotai#1912 (comment), I thought it would be great to be able to iterate through open files. However, now the code is written, I realise we probably won't need it, as panes contain the list of open files, so we can iterate through these lists directly.
As you suggested, I think it would be better to refactor to use atomFamilies once we have tests. And I think this PR is already quite large so we should add tests in another PR. I have created issues for that: #128 and #129