Query Handler Naming Conventions + Code Re-org

**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

**Describe the solution you'd like**
A clear and concise description of what you want to happen.

**Additional context****Is your feature request related to a problem? Please describe.**

As we are adding new query handlers and deprecating "old" code, we're running into issues with confusing naming conventions an messy code organization, with a proliferation of things named "handler" with no distinction between backend handlers (e.g. PMGD interactions) and server side "front-end" handling (query parsing and working with backend to create, issue, and handle graph DB interactions).

**Describe the solution you'd like**

We need a few things

1. A common naming convention to disambiguate query handling and interactions between the front end server side logic (parsing, creating, running operations, etc)
2. Consider changing code organization to include one or more subdirectories specific to the above "front" and "back" end modules. This should both improve organization and readability, and improve clarity for code re-use.

**Additional context**
Discussion needed to reach agreement on naming and organizational scheme, as well as coordination to make sure we dont massively break ongoing development.