Introduce `Client` type. Introduce and implement `LockImportRun` interface

[timwu20]

Issue summary

Taken from design doc regarding introduction of the Client type (link):

I propose introducing a similar client.Client type that will fulfill the storage, block import, and finality notifications in a similar way. Translating the primitive types and the BlockchainEvents and PreCommitActions traits into interfaces will be quite easy. Implementation of these interfaces can closely align with the reference substrate code. The chief dependency of the subtrate Client is essentially the sc_db::Backend. ...

I also think the introduction of Client will provide a foundation that allows us to implement more of these smaller traits, which comprise the full scope of the substrate Client. Some of these traits are essentially the BlockState and StorageState interface functionalities that have already been introduced on the refactor/client-db branch and are described in api.Backend and implemented by db.Backend.

Taken from design regarding LockImportRun (link):

The code that implements import_block utilizes the LockImportRun trait which contains a single lock_import_and_run function. I propose to translate and implement the LockImportRun trait first given it is a dependancy for BlockImport methods. By implementing the full logic of LockImportRun, there are calls to fire off the storage, finality, and block import notifications after a successful import.

Acceptance Criteria

• Introduction of Client type utilizing db.Backend.
• Introduction of LockImportRun interface.
• Implementation of LockImportRun interface.

Other information and links

• substrate reference to LockImportRun.
• substrate reference to Client