Fix #88: add boundbox operation

[juliohm]

This PR refactors the bounding box operation as discussed in #88. After it is reviewed and merged, I can start working on other improvements to the codebase.

[juliohm]

Hi @SimonDanisch is this PR ok? I am waiting on your approval to continue with more PRs.

[SimonDanisch]

Iooks ok, although will be a relatively big breaking change ;)
Why the rename to boundbox.jl, though?

[juliohm]

Iooks ok, although will be a relatively big breaking change ;)

I think we will need some more like these before a GeometryBasics.jl v1.0.0 :) I am doing my best to break things as early as possible in favor of a cleaner, more maintainable codebase.

Why the rename to boundbox.jl, though?

I thought that boundingboxes.jl was too long, but I can undo the renaming, would you prefer it? Meanwhile I will change it to boundboxes.jl (plural) to follow the convention of other files.

[juliohm]

Done :) Please let me know if you prefer the longer boundingboxes.jl and I can push the change as well before merging. Otherwise, feel free to merge and I will start working on a new PR for #91.

[SimonDanisch]

Please let me know if you prefer the longer boundingboxes.jl

Yeah, definitely prefer the longer one :) No need to be greedy here ;)

[SimonDanisch]

Master needs to be always taggable - since I don't immediately want to tag a breaking 1.0, I'd prefer not merging any of these.
If you want to combine all your breaking changes into one branch, I propose creating a v1_release branch, into which you can combine all your changes ;)

[juliohm]

So it is better to tag breaking changes in a separate branch? Could you please advise on how I should proceed?

I understood I should close this PR, and instead work on a separate branch of the repo until things settle down. Isn't it more painful to break everything at once when this big merge occurs as opposed to little breaking changes every now and then? The plan is to tag v0.4, v0.5, v0.6, ... until we get stable enough for a 1.0. Would that be ok?

I will rename back to boundingboxes.jl as suggested.

[SimonDanisch]

tagging a breaking releases has lots of organisational overhead for me, due to all the dependencies of GeometryBasics, which I mostly maintain alone. Since the changes are usually relatively small per package, I prefer to do multiple ones in one go.
If it's foreseeable, that we do ~3 breaking changes, I'd rather put them into one tag ;) If we don't really know what's coming over a longer time range, we could apply your tactic.

I'd just create a new branch, and change the base of this branch against that, which should be pretty easy with github ;)

[juliohm]

Makes sense. I will try to follow the rebase instructions to move the changes over a new branch.