Consider sharing implementation with graphene-django

### Problem ###
I was surprised to see that [`graphene-django`](https://github.com/graphql-python/graphene-django) shares a considerable amount of code with this library. Almost line-for-line in some instances if you blur your eyes to the types. Unfortunately that means it also shares some common bugs, missing features, etc...

Worse-off for this library, the [graphene "team"](https://graphene-python.org/team) seems to prefer `graphene-django` by a 3-0 vote. Which might explain why that package has additional features over this one 😉. Not to mention, there also several `graphene-django-*` packages that tack on to `grpahene-django`[1]

Both libraries essentially represent the same thing: gluing your Python SQL ORM into graphene types. (Note that these aren't the only players on the field either [2])

### Proposal ###
Find the middle ground for "here's how to take a declarative ORM and transform it into `graphene` types", and have `graphene-django` and `graphene-sqlalchemy` fill in the ORM-specific slots (how do I convert this ORM field type to a `graphene` field type?, etc...) and add additional features offered by that ORM.

This means that contributors who can bring valuable `graphene` expertise can contribute without heavy knowledge of an ORM, and aren't splintered across repos. Valuable features can be added to a single scaffold repo and then be filled by the implementation-specific repos much easier.
It would also mean core features/issues are located in one library.

I've outlined below (what I think) the key features that a shared library should attempt to solve, in addition to reducing the amount code copied between the two libraries.

### Similar issues/features ###
Description | django issue | sqlalchemy issue
------------ | ------------- | -------------
don't overfetch data| [402](https://github.com/graphql-python/graphene-django/issues/402) | [134](https://github.com/graphql-python/graphene-sqlalchemy/issues/134)
field/node level permissions | [485](https://github.com/graphql-python/graphene-django/issues/485) | [186](https://github.com/graphql-python/graphene-sqlalchemy/issues/186)
filtering | supported | [110](https://github.com/graphql-python/graphene-sqlalchemy/issues/110), [16](https://github.com/graphql-python/graphene-sqlalchemy/issues/16)
N+1 | `graphene-django-optimizer` | [35](https://github.com/graphql-python/graphene-sqlalchemy/issues/35)

(there's more issues/features duplicated between the two, but those are the "big ones" IMO that stop these libraries form being true works of art)

### drawbacks ###
With maintenance being scattered, it might be hard to find the right people to create/maintain such a library. Furthermore, maintenance/contributions would need to generic enough to satisfy several downstream libraries. However, from what I've seen scouring the issues and related libraries, there's no shortage of people willing to solve the hard problems. 👍

#### notable parties ####
@syrusakbary @jnak @Nabellaleen @Cito @patrick91 (plus whoever else y'all wanna tag)

#

[1] [`graphene-django-tools`](https://github.com/NateScarlet/graphene-django-tools), [`graphene-django-optimizer`](https://github.com/tfoxy/graphene-django-optimizer), etc...
[2] @coleifer who authored [Peewee](http://docs.peewee-orm.com/en/latest/) showed interest in support ([graphene#289](https://github.com/graphql-python/graphene/issues/289)) but recently said it wasn't being pursued ([peewee#1790](https://github.com/coleifer/peewee/issues/1790))