refactor chainio clients

[samlaf]

Fixes #26 .

Managed to get rid of the elChainClient struct by forking abigen to generate interfaces for the structs it generates, and using those interfaces directly in the elWriter/elReader/elSubscriber structs. There's still a bit of clutter (see the few TODOs I left). I think for example we should change the interface of the writers/readers/subscribers to take the geth Call/TxOpts directly, instead of taking a ctx and wrapping it manually in a Call/TxOpts. Also should be reusing the bindings struct to have nicer constructors. I left the elContractBindings struct there for this purpose, since I think we should repurpose it as a constructor (maybe move it to chainio/constructors actually..)

@shrimalmadhur @NimaVaziri please review these changes. If you like them, I'll do the same for the AVS clients.

[samlaf]

@shrimalmadhur need new review. This is almost ready to go. One thing I'm thinking of doing though is changing the interfaces for all our el/avs readers/writers/subscribers, and have them expose the same interface as the bindings themselves (eg. take a callOpts or transactOpts directly instead of a ctx). Thoughts?

Also did you change the settings of the linter at any point? I didn't change anything with the metrics examples afaik and not it's complaining that EigenMetrics is an unknown identifier (I think because EigenMetrics is in metrics pkg whereas the example test is in metrics_test pkg.. but unsure) EDIT: fixed

[samlaf]

Ok so main question left to complete this refactor @shrimalmadhur @NimaVaziri is what interface we expose for the el/avs reader/writer/subscriber clients. Right now we only expose some ad-hoc methods and add them as we get new needs. For eg

2 remaining questions for me are:

• as I mentioned in the previous comment, I think we should get rid of the ctx arguments and replace them directly with the geth.bind TransactOpts/CallOpts/FilterOpts which wrap a context with extra arguments and give more flexibility to the caller for how they wish the tx to be sent.
• do we want to keep these APIs minimal, or should we just expose ALL of the underlying binding methods (all the ocntract methods basically). I think there is a problem with doing this in that if we just use struct embeddings there might be method conflicts b/c all the different contracts are initializable for example so all have the same init() method which go doesn't like... but there might be a way (?)

[samlaf]

@shrimalmadhur all changes are in. Ready for final review (hopefully)!