WIP: Introduce new config options for blacklisting by Origin

[markkrj]

Fix #319

This allows users to blacklist origins (by pattern) instead of individual packages.
This way, we would not need to change configurations for every package installed from a third party repo, and instead blacklist an entire repo.

I renamed and refactored some functions to better reflect what they do and avoid duplicating code and also because some functions had somewhat misleading/confusing names (as is_in_allowed_origin, which checked if a version is in allowed origins and ver_in_allowed_origin, which returns a version from a specified set of origin patterns).
If renaming those are not acceptable, or might be breaking, I can revert the naming changes, as it might be merely cosmetic.

I did not added tests and docs yet, as I don't know if this approach would be acceptable.

[rbalint]

IMO this should be done by pinning instead and pinning already works reliably.

[markkrj]

Imagine we have a third party repo which we use for installing some (not just one) package, and manage updates from it manually. Currently, we would need to:

1. Pin up every package coming from 3rd party repo and add the repository to allowed origins
   • This would cause u-u to update packages from 3rd party, which might not be desirable
2. Pin down every package coming from 3rd party repo to <100 in official repos
   • This require extra work for every package we which to install from 3rd party.

From those options, only 2 would be acceptable, but then we would need to pin every package we install from 3rd parties, and hope to not forget anyone. With the option introduced by this PR, we could pin down an entire repo, from which we intend to manage updates manually.

[rbalint]

#287 has a more generic proposed solution for this problem

[markkrj]

#287 has a more generic proposed solution for this problem

How would we solve this problem with APT config?

[rbalint]

#287 has a more generic proposed solution for this problem

How would we solve this problem with APT config?

Unattended-upgrades could use additional APT preferences, too, where users could set u-u-specific pinning.

[markkrj]

#287 has a more generic proposed solution for this problem

How would we solve this problem with APT config?

Unattended-upgrades could use additional APT preferences, too, where users could set u-u-specific pinning.

If the implementation of that proposal respects pinning for disallowed repositories, then yes...