Move prop:field-name->accessor and friends to Racket

[samdphillips]

Pros:

1. #lang racket structs can participate in Rhombus dynamic lookup
2. #lang racket programs can use dynamic lookup
3. With the property in Racket these libraries will not need to be dependent on Rhombus
4. In Rhombus programs, structs with the property can have dynamic access without having to make a wrapper object.

Cons:
(... I can't think of any offhand ...)

[mflatt]

It could make sense to put prop:field-name->accessor and prop:field-name->mutator in either Racket or a separate little package, but I think there are some issues with a not-Rhombus-specific library:

• Natural names for fields in Racket are sometimes not good Rhombus names, and vice versa, and some future language X might have a third convention. This naming issue seems like a significant obstacle to wrapper-free interoperability.

• For primitive values like strings, vectors, and so on, Rhombus has a "builtin-dot.rkt" module that calls set-builtin->accessor-ref! to set the Rhombus-level dot dispatch. That doesn't compose or generalize easily.

As a lesser issue, the current implementations are too tied to the Rhombus class representation with an ad hoc field-names+ht+method-ht initial representation that is adjusted by the property guard. The Rhombus layer could use a derived property for its ad hoc representation, though.

[samdphillips]

Natural names for fields in Racket are sometimes not good Rhombus names

This makes sense.

As a lesser issue, the current implementations are too tied to the Rhombus class representation

Agreed.