Improve the core datastructures and traits, and make the {Stable,Beta,Nightly}Releases structs merge-able (0.2)

[foresterre]

• The previous structs and traits were not great; they were defined in a sort of inverse relationship
• rust-releases-core should focus on providing structs which define the releases and their metadata.
  • I also added a "context" C generic, which allows for data to be added by specific source implementations (e.g. the rust-dist could add some s3 bucket metadata).
  • This does have a disadvantage that functions like the new merge are more complex as a result.
  • Perhaps we should leave it out initially, and add context versions of the {channel}Release structs later?
• The previous version of core focused more on fetching data from a source, while that is very much source specific. As a result, implementations almost need to work around the FetchResources trait implementation.
  • In this version, we let source impl crates deal with the fetching themselves. That is, they no longer "need" to implement a common trait to do so. Instead we focus on defining truthful structs which define a Rust release. Each impl can figure out how to build that for themselves
• We will add methods to do common operations
  • E.g. available versions so a source impl. only needs to fetch the remainder
  • E.g. push new versions (consider conflicts)
• We added support for nightly and beta releases, in addition to stable (which the current version also has)
• We focus on a consistent API surface
• We will add a way to merge two StableReleases (idem. for the other channels, and the total RustReleases) into one, so two different release sources can be combined
  • By having this context generic C, we can enhance the context on merge, e.g. merge(RustReleases<C1>, RustReleases<C2>, f) -> RustReleases<C3>
  • We do need to add a function to determine how to deal with conflicts, or when one of the two does have a value, but the other does not. -> Prototyping phase for (conflict) resolution. This is the f in the above signature.
• We will add a new release source based on Rust's github releases, which should be reasonably reliable and very fast to fetch
  • reliability: in the past it happened that releases were already published days before the merge to the stable branch was made, which results in the github release tagging
  • fetch speed: the advantage over using the S3 buckets
• This release will break the complete API

After these changes, the current roadmap is as follows:

• Release sources should give more control over (on disk) caching to the caller
• Build a static releases crate, which can act as a build in source
  • So far this was only useful if you would then be always up to date with the crate, but by allowing merges with other sources, you can merge(static, github-releases, f: prefer static) sources