Support non-dynamic object types

[Arithmomaniac]

Right now, you need an object type Guid (as the input to RelativityObjectAttribute to define a Gravity class . This excludes all non-dynamic object types, such as saved searches and fields, from being present in a Gravity model as associated objects. At @Milyli, these field types frequently show up in configuration RDOs, limiting Gravity's usefulness.

We should allow object type to be defined by an ArtifactType as well for these scenarios (e.g. [RelativityObject(14)] for a field).

The fields themselves have Guids, so the other attributes would not need new overloads.

This might be easier to do after #158.

[mrobustelli]

Could we/should we do something with mapping? For example, come up with our own guids for the objects then if those guids are used, we handle them a special way. This way as those objects become supported by Relativity it would be a matter of just removing them from the mapping dictionary and everything should still just work?

[Arithmomaniac]

That would work as well.

[mrobustelli]

We are in agreement the reference should be by Name vs Guid for these objects.