Add support for Class and Object on top of Properties.

[mikeurbach]

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Sending a draft now, thought it isn't quite ready.

Type of Improvement

• Feature (or new API)
• API modification
• API deprecation
• Backend code generation
• Performance improvement
• Bugfix
• Documentation or website-related
• Dependency update
• Internal or build-related (includes code refactoring/cleanup)

Desired Merge Strategy

• Squash: The PR will be squashed and merged (choose this if you have no preference).
• Rebase: You will rebase the PR onto master and it will be merged with a merge commit.

Release Notes

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels? (Select the most appropriate one based on the "Type of Improvement")
• Did you mark the proper milestone (Bug fix: 3.5.x, 3.6.x, or 5.x depending on impact, API modification or big change: 6.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[jackkoenig]

This is a pretty large discussion topic but I am not a huge fan of the current untyped approach using dynamic. The entire purpose of Definition/Instance was to give this sort of API while maintaining type safety. I really think we should just bite the bullet and make D/I be the intended way of defining and instantiating Classes.

Now I understand that we have some use cases that require an unsafe API for just instantiating classes by name when you certainly are not going to know anything about the actual typed interface. But rather than making the normal API embrace this untyped route, I think we can just implement that particular API directly without having its untyped-ness impact the more typical user API

val inst: DynamicObject = Class.unsafeInstanceFromName("MyClassName"))

Depending on how hard it is to implement D/I for classes, we could punt on implementing it fully and just make Definition[Class] work, then use this unsafe API as the only API to instantiate an object for the short term.