Introduce abstractions

[janek26]

The API we want to expose with this package has rapidly expanded.
I think it'd be good timing to discuss the exposed methods and objects, to prevent future surprises.

I really like the simplicity introduced by @seanjameshan initially, by exposing the api endpoints as is. But with introducing more complex types like contracts and accounts we need to find a middle ground.
I'd like to introduce a simple yet extensible api for developers to use.

Simple and extensible api:
Lets assume defaults, but also expose the building blocks used onto of those defaults.
ie: Starknet Goerli Alphanet is the only one accessible right now. This won't stay this way, with main net approaching quick. Lets always expose a simple (opinionated) export to get the developer started right away, aswell as a class contructor where you can pass your own arguments.

// Beginner
import { api } from "starknet.js"

// assuming goerli alpha and subject to change
const { Starknet, GpsStatementVerifier } = await api.getContractAddresses()

// Advanced
import { Api } from "starknet.js"

const localApi = new Api({ endpoint: "http://localhost:3002" })
const { Starknet, GpsStatementVerifier } = await localApi.getContractAddresses()

Classes:
On top of that I think it makes sense to introduce some Classes, to leave the choice of if a develop wants to use OOP or a more functional style. ie:

// functional
import { wallet } from "starknet.js"

const { getKeyPair, sign, getStarkKey } = wallet

const kp = getKeyPair("Private Key")
const address = getStarkKey(kp)
const sig = sign(kp, "hello")

// object oriented
import { Wallet } from "starknet.js"

const wallet = Wallet("Private Key")

const address = wallet.getStarkKey()
const sig = wallet.sign(kp, "hello")

[0xs34n]

Regarding the Simple and extensible api:

Would the below make sense?

import { starknet } from "starknet.js"

// assuming goerli alpha and subject to change
const { Starknet, GpsStatementVerifier } = await starknet.getContractAddresses()

// set the gateway from default to custom
starknet.setGatewayUrl("http://localhost:3002") // or setCustomGatewayUrl() to be more explicit
// get contract under new gateway url
const { Starknet, GpsStatementVerifier } = await starknet.getContractAddresses()

Regarding Classes:

Perhaps below would make sense

import { starknet } from "starknet.js" // or import { Wallet } from "starknet.js"

const wallet = starknet.createWallet('<<Private Key>>') // or wallet = new Wallet('<<Private Key>>')

const publicAddress = wallet.getStarkKey()

const signature = wallet.sign('hello')

I'm afraid if we maintain multiple implementations of the same logic in different places: advanced, beginner, object-oriented and functional logic, it would be difficult to maintain. Any logic changes would have to change in 2 or more places.

For the api, since we do currently have a default, it does not have to hold state unless we want to change the state. Perhaps we should also ask the developer to set this explicitly before using starknet. For example new Starknet('test') or new Starknet('main') or new Starknet({ gatewayUrl: "http://localhost:3002" }). We can revisit this when mainnet and testnet are both live.

On the other hand, the wallet needs to hold a custom state initialized by the user from the beginning, so class may make sense in that case.

Thoughts? @janek26