Additional package publishing support to nimble
**Scenario:**
Due to the ease-of-use of nimble and nim (overall, as a language), I've ended up with a bunch of small packages/programs that i wrote to solve trivial problems in my development environment and shell config (checking email, calendar, contacts, etc). As a result I have a bunch of repos of nimble-packages that i use daily. Originally I kept making package formulae to install them via homebrew/linuxbrew (my package manager of choice) but this has grown really tedious and only requires a lot more boiler-plate be maintained for the sake of just myself. So, instead of going through the cycle of "making local changes -> push to GitHub -> reinstall package from HEAD via brew", i've switch to creating a local package list for nimble instead.

**Friction:**
Overall this has been pretty good, it required I make some changes (for the better) to some of the nimble packages I have to handle hybrid packages the correct way. The major source of friction here is maintaining my local custom packages list. This requires manually writing in new json for each package I want to have access to and sync across workstations with my dot-files so I can ensure that my working environment is always the same. I really don't like writing json.

**Proposal:**
Adding support to `nimble` to:

1. publish a package to any package list known to `nimble` (assuming it isn't read-only/published via a platform with no interface to make changes)
2. add optional meta-data to the `.nimble` file that specifies the package-list to publish too
3. handle publishing a package to a package-list that doesn't require forking to make a contribution to (eg: a package-list repo on the same account as the access token is for (don't try to fork your own repo))
4. better define the steps of publishing a package (due to cases outside of the official package list) and the requirements/expectations a user should have when performing the `publish` command.

---

I realize that this covers a lot of stuff and there is probably a lot I haven't considered about this yet I think the major/top-level points are covered here and hashing out the details of each scenario/use-case can be done as this work gets implemented. I wanted to see if my proposal here aligns with your road-map and how best to approach implementing these features.