Consider renaming Source to Object

[kelle]

Turns out LSST uses the words "source" exactly the opposite of our implementation. They use the word "object" to mean the same physical object detected across space and time and the word "source" to mean a detection of light regardless of its association with an "object".

Do we want to consider switching at this point? Eg., We would have an Objects table and "object" as primary keys instead of Sources table and "source". I don't feel strongly. @dr-rodriguez?

cc @RileyWClarke, @easton-honaker

[kelle]

see #151 (comment)

... DIASourceIds, i.e. ids corresponding to the individual Rubin exposures. And then multiple DIASourceIds could link to the same entry in Sources, which are DIAObjectIds from Rubin.

[dr-rodriguez]

There is no right answer when it comes to column/table names. PanSTARRS calls their detections detectID, for example.

AstrodbKit is flexible enough to take a specified "source" column name- it's something you can provide as an optional parameter. We probably don't want to change the astrodbkit default; if we do that may break a lot of downstream scripts. My expectation has always been that users will rename this column and set the appropriate value in their scripts. If anything id may be a better column name.

As for table names, I feel Source is clearer, and more astrophysical than Object. But again, this is a tunable parameter and I expected users would name it things like Galaxies or brown_dwarfs, depending on their preference.

So, I recommend keeping as-is.