[DISCUSSION] Library Upgrade - Part 2

### What is wrong?
The first part of the upgrade is over, where the `fields` used by different curves were generalized into the `fields API`. Regarding the 2nd part of the upgrade, this is what I had in mind.
* Remove different modules for the different curves (`bn128`, `bls12_381`, `optimized_bn128`, `optimized_bls12_381`) and generalize it into the `curves API`.
* In the `curves API`, all the **common functionalities** amongst all the above mentioned curves go into the `class BaseCurve` and `class OptimizedBaseCurve`. And the respective curves would `inherit` these base classes.
* All the **non-common functionalities** go into each `subcurve implementation`.
* We could then create an object of each of the curve, and place it in `__init__.py` so that users can directly import the respective `curve object`.
* This could be considered as a **Breaking API** for the following reason. There are 2 scenarios regarding how the users import and use this library.

**Scenario 1**
```
from py_ecc import bn128
...
...
a = bn128.G1 # Some operation involving G1
b = bn128.G2 # Some operation involving G2
c = bn128.is_on_curve # Some operation involving is_on_curve function
...
...
```

**Scenario 2**
```
from py_ecc.bn128 import (
G1,
G2,
Z1,
Z2,
is_on_curve,
...
...
)
...
...
a = G1 # Some operation involving G1
b = G2 # Some operation involving G2
c = is_on_curve() # Some operation involving is_on_curve function
...
...
```
Here, `Scenario 1` **won't** be a `breaking API`, but `Scenario 2` **would be** a `breaking API` for the further releases.

### How can it be fixed

/cc @pipermerriam @carver @ChihChengLiang @hwwhww