Update to scheme version 4.0.0

[deathaxe]

This PR introduces required changes to support scheme 4.0.0 for Package Control 4.0

Overview

1. Updates database scheme to
   • replace dependency by library
   • add python_versions key
   • drop load_order
2. Provides a setup/sql/migrations/library.sql script to update production database.
   Tested by creating a DB with 3.0.0 scheme, fetching some libs/packages and finally running library.sql
3. Updates related controllers/models/views/libs/tasks to make use of new database scheme.
4. Pull in package_control from https://github.com/wbond/package_control/tree/four-point-oh
5. Add a generate_channel_v4_json task and update generate_channel_v3_json to only provide PC.

Why channel_v4.json

Package Control 4.0 handles both 3.0.0 and 4.0.0 schemes well. Just requires 4.0.0 to pull dependencies/libraries for python 3.8. So its safe (and required) to publish it before this PR is published to packagecontrol.io

If we would keep going with channel_v3.json and just update its scheme version no Package Control 3.x client was able to fetch packages from official sources due to mismatching scheme version. We would end up in users needing manually update Package Control, which may cause some complains.

By providing a dummy channel_v3.json with only Package Control in it, all clients have a chance to update to 4.0 even after packagecontrol.io is updated.

In the meanwhile Package Control 4.0 can be preconfigured to pull in channel_v3.json and channel_v4.json, so it keeps going with v3 until packagecontrol.io is updated.

This should ensure a smooth transition from 3.x to 4.0.

Required changes to channel can be found at wbond/package_control_channel#8713

[deathaxe]

For this PR to work #155 and #156 should be merged before.

[deathaxe]

Got it up and running on Debian 12 with python 3.11 and PostgreSQL 15 with a little patch to gears library.

[adamlaska]

!

[toddwildey]

@wbond Can we merge this change into Package Control? Do we require an ownership transfer first?

I would be willing to host/contribute maintenance to packagecontrol.io to get this merged.

[deathaxe]

Package Control is critical for Sublime Text package ecosystem's security.

It should therefore be hosted and administrated by trusted and well-known actors, only, especially after recently disclosed XS supply chain attack, which targeted compromizing SSH connections of widely used linux distributions.

[toddwildey]

1. I've been using Sublime Text for almost ~15 years.
2. I currently operate as a Senior Software Development Engineer at Amazon professionally, where I've worked for full time for nearly a decade.
   1. Compromising security for Package Control or Sublime Text is absolutely not in my best interest professionally.
   2. More so, I can help establish zero-trust mechanisms that require trusted maintainers to curate the channel.
3. I am happy for someone else to maintain the packagecontrol.io repository, but progress on the repository appears to have stalled out for the last 3 years due to @wbond's effective departure. It is critical for the success of Sublime Text and all the developers who use it for Package Control to not be blocked by one person.