fix: histogram weights not handled correctly in hist / boost conversion

[lobis]

Currently the fSumw2 (weights) are not being correctly read/written when performing conversion to/from hist/boost histograms.

This is causing issues in #672 and solving this will also close #722.

• We now use hist storage_type property to check wether it's a weighted histogram or not, instead of the variances which is always defined and was cuasing false positives.
• Add two new tests, to check the conversion with a histogram with weights and another one without weights.
• Updated slicing of values / variances for categorical axes.
• Refactored weighted property and to_boost method to use inheritance.
• Write test for 2D, 3D histograms with weights / labels.

[lobis]

I refactored weighted property and to_boost method using inheritance with the goal of reducing code replication. However perhaps there is a reason this was not done in the first place, and I can see lines such as no_inherit = (uproot.behaviors.TH1.TH1,) hint me to think this way.

Let me know if I should remove it @jpivarski or if maybe I should have made a separate PR for this. Perhaps I should've implemented it in the TH1 class instead of Histogram class.

[jpivarski]

Very nice! All of my requested changes are inline.

[lobis]

Looking at the code of TH{1,2,3}.py I see it can be refactored in a similar way to what is done in to_boost in this PR (implement to_numpy, etc in Histogram). This would leave only axes property and perhaps the axis method on TH{1,2,3}.py.

I don't think the complexity of the code increases enough to discourage this and it would reduce code duplication (triplication!), but I would love to hear some thoughts @jpivarski @agoose77.

[jpivarski]

Generally, I didn't worry about code duplication up to three, particularly if it was right next to each other and formed a clear pattern. (The problem with duplicated code is that a future maintainer might fix one copy without applying the same update to the other copies, and then they get out of date until another future maintainer wonders if they were supposed to be the same or not.) In the case of histograms, I knew that the code duplication/triplication would never go beyond three, since ROOT only defines 1, 2, and 3-D histograms.

I'll let you decide whether you want to squash more duplication. As it is, I would accept this PR now. So if you consider yourself done, go ahead and do the honors by pressing the "squash and merge" button. (Make sure it's set to "squash and merge" mode; we don't want all of the commits in this PR to be individual items in the global history.)