Add more comprehensive interface to SDK

[kael-shipman]

As a consumer of the Tokensoft SDK, I would like it to provide more comprehensive functionality and be somewhat opaque as to whether that functionality is API-based or blockchain-based. To this end, I've incorporated the SDK into our clearing system in the way that feels best to me and have used that to inform my thoughts on what the public interface of the SDK should be.

In general, with the exception of the new blockchain methods, my approach has been to simply provide concrete pass-throughs to the existing GraphQL API functions.

Blockchain Handling

Having dealt with Web3 and its expansive and poorly-conceived interface, I think adding a web3 dependency would be a mistake. Therefore, I've taken some essential definitions from the Web3 types (v1.3.4 at the time of this writing) and created a minimal interface that is Web3-compatible. This should make it easy to simply provide a modern instance of Web3 if you have one, but also allow you to relatively easily implement an adapter over whatever you do have.

Additionally, I propose that we not make this mandatory. Certainly many users will not be interested in using the blockchain functionality in the library, and we don't need to make them subscribe to that. I propose (and have implemented) an optional constructor argument for the web3 dependency.

To-Do

• Create basic ethereum/web3 abstraction interface
• Create passthrough method for detectTransferRestriction
• Create passthrough methods for certain essential user functions
• Create functions for performing a token transfer - No longer necessary for our use-case, so will not implement

[kael-shipman]

It has also occurred to me that it's possible the Tokensoft API and SDK were actually conceived to obviate the need for any blockchain interactions. If this is the case, then I would like to propose that the API commit to fully covering the functionality mentioned, including "get" functions like detectTransferRestriction and even balanceOf. While that may seem redundant, if the value-add of the API is that it obviates the need for interactions with the blockchain, then it should do so completely.

[kael-shipman]

@masonicGIT and @cr-walker I've finished the work that I'm going to do for Openfinance's purposes. If you think this will be useful to you, please consider merging it. Otherwise, please close this PR.

Note that the way I've now implemented most of the GET methods is with an additional projection parameter that the user must specify to indicate what fields to retrieve. To get a user by email, for example, I could perform either of these calls:

const user1 = await tokensoft.getUserByEmail("me@example.com", { id: true });
console.log(user1.id);
// console.log(user1.email) // ERROR! email is not defined on type { id: string }

const user2 = await tokensoft.getUserByEmail("me@example.com", {
  id: true,
  email: true,
  emailVerified: true,
  kycUploadFiles: {
    uploadId: true,
    value: true,
  },
  rounds: {
    name: true,
    commitmentAmount: true,
  }
});

console.log(user2.id);
console.log(user2.email);
console.log(user2.kycUploadFiles.length);
console.log(user2.kycUploadFiles[0] && user2.kycUploadFiles[0].uploadId);
// .....

If you like this, you might consider adding additional graphql functions to the SDK to make it more complete. Lemme know what you think.