Warnings cleanup and Project Reorganization

[1whatleytay]

I think it's time to rip off the bandaid! This PR's end goal is to reorganize the project and get rid of as many warnings as possible. Some things this PR does:

• We remove author comments. TA feedback specifically mentioned these, they also cause 1 warning per raw GitHub link we mention, so we'll be using VC instead for the time being.

• Reorganize packages, all classes of a related certain layer (Entity/Application/Interface/Frameworks) should be in their own package. Right now package names and interfaces are a bit all over the place, so this PRs goal is to fix this.

  There's a new project structure! I'm down for feedback, but this is the way that made more sense to me. GET YOUR PRs MERGED ASAP so I'm the one who has to deal with conflicts. There could be still some classes I forgot to work with, LMK if I missed anything:

For all client classes:

• arguments: Classes related to ArgsParser. Contains ArgsParser and some parsing utilities.
  • parsers: All CommandParser implementing classes. These classes should talk to controllers in client.commands.controllers.
• commands: A side-effect less package for controllers/presenters. No printing to stdout here.
  • controllers: All use-case controllers. They should interface with presenters in client.commands.presenters.
  • presenters: Presenter boundaries. Since controllers should not really write to stdout, we want the actual implementation to be in client.display.presenters.
• database: Interface classes related to interacting with a database. Actual classes that make net requests or interact with the file system should be in client.local.
  • fetcher: Database fetcher related classes.
  • mirrors: Mirror model and interface classes.
  • tracker: PluginTracker model and interface classes.
• display: This package is renamed from interaction (since we have a ton of "interactors" in our project that aren't in this package). This is the home for presenters and other classes that write to stdout.
  • presenters: Put the implementation for presenters here!
  • progress: Put ProgressBar related classes here!
• local: ALL INTERACTION WITH NET/FS should be done here! Let's keep this contained. I called it local since most net related classes seem to also interact with the "local" filesystem. Not totally sure how that works.
• models: I believe entities should live here. So Plugin/Database related classes.
• export: Export use-case related classes here. Anything that doesn't write to stdout or deals with interface classes is OK.
• injector: Hot reload related classes here. This directory is a bit privileged to talk with Spigot (which is a side effect). Up to you if you want to split that out into another directory.
• installer: Installer related classes. Again, no writing to stdout.
• list: List-locally installed plugin related classes here (Kevin's use-case).
• matcher: Not a real use case but its used for the updating system (e.g. related versions). Unsure if it's still needed but I'm keeping it around in it's own directory for now.
  • search: Search use-case related classes here!
  • uninstall: Uninstall related use-case classes here! Again no stdout or file-system if possible please. Might want to make like a PluginDestination interface and work with installer on this one.
  • updater: Update related use-case classes here!

[projectavi]

Wow this is so cool! Imagine if it were written in a non esoteric programming language like Kara! Highly Recommend: https://github.com/1whatleytay/kara!