fixes #175 - updated regex to find a signed package on /plugin_package page

[7thsky]

fixes #175

the current implementation tries to parse a package's remote path from <a .../> on /plugin_package. that link is not always correct ( for example if you device has a sdcard installed )

/plugin_package page response always have var params = JSON.parse('......') line. And the actual link ( when you opens the page in the browser ) built from the following js

var pkgs = params.packages.filter(p => p.pkgPath !== "");
var hasPkgApp = pkgs.length > 0;
{
  var pkgDiv = document.createElement('div');
  if (hasPkgApp) {
    var package = pkgs[0];
    var pkgPath = package.pkgPath;
    var pkgName = package.pkgPath.substr(package.pkgPath.lastIndexOf('/') + 1);
    var size = package.size;

    pkgDiv.innerHTML = `<label>Currently Packaged Application:</label>
      <div>
        <font face="Courier">
          <a href="${pkgPath}">${pkgName}</a>
          <br> package file (${size} bytes)
        </font>
      </div>`;
  }
  else {
    pkgDiv.innerHTML = `<label>Currently Packaged Application:</label>
      <div>
        <font face="Courier">
          Application is not yet packaged
        </font>
      </div>`;
  }
}

[TwitchBronBron]

Hey, this is great! Thanks for your contribution.

I pushed a small change that includes a test for the old logic, and added the old logic back in as a fallback if the json approach doesn't work. Since this is a fairly significant change (logically) from how we derive this value, I'm hesitant to 100% switch to the new way, so having the fallback feels like a good compromise.

Do you mind pulling this version down and testing it? Once you're good with my changes, I'm happy to merge and cut a release.

[7thsky]

@TwitchBronBron yes, the fallback is a good idea. tested locally on one device with sdcard and without. works fine for me.