Add update feature to admin panel

[ccoverstreet]

Right now, there is no quick way to update a JMOD. This process should be made as easy and simple as possible to encourage users to update. A decision on how to handle JMOD versions must be made in order to implement this feature. Personally, I see no reason to allow for multiple versions of the same JMOD to exist at the same time (when downloaded from GitHub). This greatly simplifies the upgrade process by keeping the same data directory and passing it to the new JMOD version. Since not all updates may progress smoothly, I may create a method for letting users pin a JMOD to a specific version or tag.

A sample upgrade process may look like this:

1. User click's update on the JMOD in the admin panel
2. A update request gets sent to Jablko Core
3. Jablko Core checks if current tag is different than the tag on GitHub for the default branch
4. Jablko downloads the new source
5. Jablko stops the current JMOD
6. Jablko starts the new JMOD passing the data directory and prior config
7. The user is then responsible to either update to a prior version

The default argument for update would be latest and would follow the above process. Alternate arguments would be the tag of the version the user wants to update to. On the admin panel, it may be better to just have users enter the JMOD name with a new version argument instead of having a button for each JMOD. That way, installing and updating JMODs is done by the same method.

[ccoverstreet]

The design decision to only allow one version of a JMOD could also simplify how JMODs are accessed. Right now, JMODs downloaded from Github could have a near infinite number of @commit endings, which makes tedious to update the JMOD name on an external device. A proposed change to the JMOD format would be removing the @ suffix and storing the commit name inside of jablkoconfig.json somewhere. One way to do this might be to nest the actual module config within a Jablko specific config:

{
  "jmods": {
    "github.com/author/jmod": {
      "commit": "abcdef",
      "maybeOtherFields": "here",
      "config": {
         "stuff": "here"
      }
    }
  }
}

This kind of design would allow for more control over JMOD behavior like limiting the number of threads a JMOD can use

[ccoverstreet]

Big whoopsie, with the new config format, there is a really weird recursive config effect that occurs when trying to update the JMOD config.