BoundingBox: add area/volume attributes

[adamjstewart]

This PR adds area/volume attributes to the BoundingBox class.

This is needed for a check I would like to add for #319, but I figured I would submit it as a separate PR to keep things easier to review.

[calebrob6]

It feels weird multiplying area by time and having "volume" in a "Bounding Box", what is the bigger picture?

[adamjstewart]

Bounding boxes in TorchGeo have always been 3D boxes, I think volume makes sense here. We could also add an area attribute that only computes the spatial area.

The context is that I'm planning on adding something like this to IntersectionDataset._merge_dataset_indices:

box1 = BoundingBox(*hit1.bounds)
box2 = BoundingBox(*hit2.bounds)
box3 = box1 & box2
if box3.volume > 0 or box1.volume * box2.volume == 0:
    self.index.insert(i, tuple(box3))
    i += 1

This is designed to help with #319. The idea is that an intersection dataset should only contain bounding boxes with zero volume if the original bounds also have zero volume (point data). This is for the case where we have two side-by-side bboxes and end up with 2 additional areas of intersection with 0 overlap. It might make more sense to use area though since maxt - mint is often 0.

[calebrob6]

Cool makes sense to me!

This would provide the area attribute for #380 as well.

[adamjstewart]

It might make more sense to use area though since maxt - mint is often 0.

Actually, this isn't true. disambiguate_timestamp resolves files to the microsecond resolution, but files rarely record the microsecond, so maxt - mint is rarely 0. But also, it's rare for timestamps to overlap. Even for sequential data like annual CDL, we subtract 1 microsecond from the end of the year, so there shouldn't be any overlap. So basically, we can use either area or volume, it shouldn't make a huge difference either way.

[adamjstewart]

Added an area attribute and clarified what we mean by "area" and "volume" in the docstrings. This should be good to go now.