Add support for EEPROM

[jgfoster]

Fixes #166. Also add testing to demonstrate use.

[ianfixes]

What information should I put into REFERENCE.md for this? It looks like it mocks the functionality, but does not interact with GODMODE in a way that would let you verify that the functions had been called a certain way. (which does not block this PR)

[jgfoster]

Actually it is fair for you to say that we need to update the documentation! How that looks is open for discussion and advice. From the beginning (only a few weeks ago) I've been unsure on how to fit in new mocks. Since the EEPROM functionality doesn't involve pins, I don't see the direct tie-in to GODMODE. As to verifying "that the functions had been called in a certain way," I'm not sure. In this case, the API is pretty much read/write. If there data is there, then then I assume it was called correctly. What more can be tested? (Not intended as pushing back, just trying to figure it out myself.)

Shall I put in a PR with a paragraph describing how to use EEPROM?

[ianfixes]

Apologies for the delay. It looks like the unit tests are all there, so all that I think remains is a short paragraph in REFERENCE.md similar to the section on SPI -- just saying that it acts like a basic read/write buffer and there is no GODMODE support at this time. (That sort of thing can always be added later -- we can open an issue to track it if/when that functionality is desired).

[ianfixes]

I'll smooth over the merge conflicts here in a bit

[jgfoster]

We should probably reconsider adding this directly since its license is inconsistent.

[ianfixes]

I'm really out of my depth with regard to the terms of all the different licenses, and really can't offer advice one way or another. I have no idea whether your own rewrite counts as some "derivative" in the way the licenses are written.

I think as long as we're doing our best and intend to respond to any legal complaints -- fixing the license as appropriate -- (which I do intend to do) then I'm not sure what else it would take to move forward. In any case, if we keep the file let's keep the license and it can all get sorted out later.

[jgfoster]

As owner of the project, you certainly have the last word on this. But (did you sense a "but" coming?), the difference between the GNU license and your Apache license is night and day (with slight exaggeration, think Catholics and Protestants in 16th, 17th, and 18th century Europe, or Antifa vs. Proud Boys today). While I can't promise that my replacement would withstand a legal challenge, I'm pretty confident that it would be better to leave out the GNU reference. Other than the file name and the published API, I made an effort to write the code from scratch and think that the risk is extremely small. By leaving in the GNU license, you risk attaching GNU to my code, and then you would need another rewrite.

[ianfixes]

I saw your rewrite after adding my comment, and I think your rewrite satisfies

[ianfixes]

I've squashed this into #183