add support for mod dependencies which are not blt-updated

[BangL]

the reason for this patch can be read here: https://github.com/JamesWilko/Payday-2-BLT-Lua/pull/48 with this solution a mod like beardlib could define `

...
"providing" : [ "beardlib" ],
...

` ... in it's mod.txt, without having to use the blt updater for itself, while mods that need beardlib would now define its dependency the following way:

`

...
"dependencies": [
    {
        "identifier": "beardlib",
        "is_not_blt_updated": true
    }
],
...

`

the table structure of a dependency is optional, and simple strings still work, while is_not_blt_updated defaults to false! of course it would also work without the is_not_blt_updated flag, the blt update server would just not return any result, but i don't see why to spam more requests as needed.

you can also define mixed dependency formats, like this:

`

...
"dependencies": [
    "delayedcallsfix",
    {
        "identifier": "beardlib",
        "is_not_blt_updated": true
    }
],
...

`

[BangL]

we could actually go even further, and support custom url's here. not sure if the effort is worth it though. let me know if somebody would use that feature, then i will add that as well.

[neico]

Git like urls (github, gitlab) might be an op feature, similar to what node's npm offers, so that might be something that can improve and especially offload things a lot (and might make forks easier to replace outdated versions)

But before we go that way blt itself should probably make updating more secure first, it currently uses http all the while there are free ssl certs trough services like Let's Encrypt by now,
not to mention update verification and signing to prevent malicious attacks given how much power a pd2 mod has over the host system... (they are more for comparing versions rather than for security, public-private key's on the other hand...)
but this should be probably addressed via a different PR / issue anyway...
Just wanted to throw that into the room.

[ZNixian]

@BangL Since there is support for custom automatic updates in SuperBLT (docs), could you please add support for custom URLs (probably by providing the meta (.json) file) and open it as a MR on the SuperBLT GitLab page.

@neico The contents of the files are hashed and verified against the meta file, so if that is served over HTTPS there should not be any security issues. Do you think I should block (or at least add a warning for) insecure meta files in SuperBLT?