add regmap package to facilitate heapless driver development

[soypat]

@ysoldak @aykevl @deadprogram
Discussion in #766 made me consider adding this logic which is common to many 8 bit address width drivers. The name comes from "Register Mapped"

I've added only the functions which have a trivial heapless solution. The trivial implementation for WriteDataSPI and WriteDataI2C would require copy+additional buffer provided so I avoided it for now to see if we can think of a solution that maybe does not require the copy, i.e: transactional API.

[ysoldak]

This PR looks more like a Draft, a conversation starter. Shall we convert it to Draft?

What do you mean by "transactional API", @soypat?

In #767 I had to allocate a buffer in I2C buser and return a part of it back to the driver to use.
Can we use something like this here probably?

[soypat]

By transactional API I mean approach something more similar to how DBs handle actions, see BboltDB's Tx method on DB type. It really is a rather complex way of approaching this and would likely not be required for 99% of drivers, so I'd rather leave it to a future conversation.

This current API is the most basic level of abstraction. We can add a dynamic buffer: Device8Buffered to cover your use case, though I feel the brunt of the work developing a new driver is this work, not the dynamic buffer length part, which can really be done in so many ways I'm hesitant to adding it. I'd like to see the pain point of needing a dynamic buffer implementation before writing it. The ssd1306 can maybe (?) get away with the following code? And it really feels like not worth generalizing just yet

type Dev struct {
  buf []byte
}

func (d *Dev) tx(data []byte) error {
    d.buf[0] = cmd
    n := copy(d.buf[1:], data)
    return d.bus.Tx(d.buf[:n+1], nil) // ...
}