Skeleton updates

[lkdvos]

This PR brings the package up to date with the skeleton v0.2.0.

Note that there is a rather large amount of ambiguities related to wrapping number types like this, which I did not yet solve here. (similar to LabelledNumbers.jl)
There are also a couple type piracies that should be resolved.

As a comment for future reference: it might be easier to define GradedAxis along the following lines:

struct GradedUnitRange{Label,T,BlockLasts,GBU<:AbstractGradedBlockUnitRange{T,BlockLasts}} <: AbstractGradedBlockUnitRange{T,BlockLasts}
  blockunitrange::GBU
  labels::Label
end

This avoids the need of having the labels being integers etc, thus circumventing the invalidations/ambiguities.

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[mtfishman]

As a comment for future reference: it might be easier to define GradedAxis along the following lines:

We can try that again, that is closer to the original design from a while ago but I moved to the latest design with the hope that we could take advantage of generic range code in Base and BlockArrays, while preserving the sector information to use it when it is needed (i.e. the sector information is "along for the ride" through generic code). I think it is still up for debate if the tradeoffs of the current design are worth it, but what I like about the current design is that when you index into a GradedUnitRange, i.e. g[2], it outputs the range value along with information about the sector. That is consistent with the fact that we want slices like g[Block.(2:3)], g[2:5], g[Block(2)], etc. to preserve the sector information.