Make the syntax of record type ID search terms consistent with other ID search terms (from 779)

[gigamorph]

While the scope of this ticket is syntax related, we're also missing data for most of the record types --at least as these search terms presently resolve to CTS queries. The remaining search terms generator was modified to only create ones that are backed by data. Based on how #709 shakes out, we may need these search terms for more than we have now.

At present, the syntax is [recordType]Id. It is to change to [recordType] that accepts an id child term.

[brent-hartwig]

@jffcamp and @prowns, the need for these search terms evaporated. They date back to a potential use for related lists that never came to be. I do not believe they are used or provide value. I propose we ditch these and question if LUX should support restricting results by record type --a lower granularity than search scope. For instance, the work search scope is comprised of three record types while the concept search scope has five. By offering record type search terms, backend endpoint consumers can submit searches that, for example, only return people and not groups, or human made objects and not digital objects. We could support it with or without a data change, but, pending above confirmation, @azaroth42 could stop creating the personId and groupId properties. cc: @roamye

[prowns]

ok to close per @azaroth42