I see that the operator module was split up! nice!

In reading the docs, it seems like there are further ways the structure of the package could match the structure of the docs and the types of objects in the package. For example there seems to be a relatively straightforward structure from the docs that would look something like

- collections
  - matrix
  - vector
  - scalar
- operators
  - unary
  - binary
  - monoid
  - semiring
  - indexunary
  - select

but currently that looks like

- binary
- indexunary
- monoid
- op
- select
- semiring
- unary
- core
  - matrix
  - scalar
  - vector
  - operator
    - agg
    - base
    - binary
    - indexunary
    - monoid
    - select
    - semiring
    - unary 

where the operators are both at the package root and also beneath core.operator, and the collections are also within the core module.

Wondering what the barriers are to refactoring here so that the code structure more closely matches the structure of what the code is doing?

part of: pyOpenSci/software-submission#81