Fix getter infinite recursion

[t-kalinowski]

Closes #403

[lawremi]

Note that a property with only a getter could be computed entirely dynamically, so we wouldn't want it in the constructor. I still think we should use the prototype approach, where the object just starts with its defaults, and there's no need to set a read-only property during construction.

Btw, there is actually a bug here, where a property with a setter (and a getter) is dropped, in error. This is addressed by the prop_is_read_only branch.

[t-kalinowski]

What should the interface be for someone looking to implement a class with a property that can be set when the instance is initially constructed but is read-only after that?

[t-kalinowski]

By the way, this looks good to me: main...prop_is_read_only

[lawremi]

See issue #404 for my proposed approach to construct-only properties.

[lawremi]

Are you sure we can use the same list for both getting and setting? Assume a setter is called and it wants to get the value of the property, I think it would be surprising that the getter is not called.

As an example of where this would arise, assume a property is fully dynamic, like the value is being stored in a database, or on a C data structure. Maybe the setter wants to make sure that the value is different before performing the change.

I think we can still share a lot of the code between setting and getting, even if we use two different lists (the list symbol can just become an argument to the functions that manipulate the list).

[t-kalinowski]

Are you sure we can use the same list for both getting and setting?

My thought process was that in property getter/setter methods, we're in "internal" territory, where accessing the property fetches the underlying attribute. However, you make a compelling case that it would be useful to be able to call a getter() from a setter() method.

I'll change the approach to allow for that.