Added additional 'add' support to OpenSCADObjects

[HowManyOliversAreThere]

These changes allow for the use of sum() on OpenSCADObject lists

• Added support for __radd__
  • Functions identically to __add__
• Added support for adding ints to OpenSCADObjects
  • ValueErrors if not 0
  • Adding an OpenSCADObject and 0 just returns the OpenSCADObject

[etjones]

So, given a list a of OpenSCADObjects, union()(a) adds them all together. Since that feature already exists, and since I'm deeply skeptical of ever adding an integer and an object (even it it's a no-op), I'm hesitant to merge this. Can you think of a situation where using sum(a) would be better than union()(a)?

e.g., here's a unioned SCAD list, and the OpenSCAD it compiles to:

a = [cube(5), right(10)(cube(5)), right(20)(cube(5))]
unioned_list = union()(a)
print(scad_render(unioned_list))

yields:

union() {
    cube(size = 5);
    translate(v = [10, 0, 0]) {
        cube(size = 5);
    }
    translate(v = [20, 0, 0]) {
        cube(size = 5);
    }
}

[HowManyOliversAreThere]

I would say that the sum(a) implementation is more intuitive when you're already working with the + and - operators, rather than union()s and difference()s. I believe it is also more Pythonic.

That said, I agree that it is functionally not adding anything new and your concerns are valid re: integer addition, so no stress if you want to just close and I'll work from my fork!

[etjones]

I think the Pythonic argument and the argument that things that can be __add__()-ed should also be sum()-able are convincing, and there's no downside here. I'll merge it. Thanks!