Clarify how can applications tell which top level element is intended

There are 3 top level elements (TLE) in phenopackets:

https://phenopacket-schema.readthedocs.io/en/latest/toplevel.html

All of the examples here:

https://phenopacket-schema.readthedocs.io/en/latest/examples.html

Use a phenopacket as a top level element

However, other repos have examples that use other top level elements; e.g. https://github.com/phenopackets/phenopacket-tools/blob/gh-pages/examples/families/family.yml

If an application is presented with a phenopacket document D, how should the application determine how to interpret it?

1. Attempt to parse using each TLE schema until it finds one that passes. Note that in certain perverse cases, this could lead to abiguity
2. The application should attempt to sniff the right TLE from the filename. E.g. in the example above "family.yml" looks like family should be the TLE
3. Behavior is undefined, and a phenopacket-conforming application must receive a tuple of two messages, both the document D plus an additional TLE type designator T

None of these seem particularly satisfactory. Perhaps future versions of phenopackets could include a type designator field in each TLE so applications can clearly and unambiguously interpret a document

Read the top-level element documentation and examples at the linked Read the Docs pages, then compare them with phenopacket-tools/examples/families/family.yml. Determine the intended way for applications to identify a document’s top-level element and document the accepted rule and any required schema changes. Done means the ambiguity is resolved in the specification or documentation.

Written by the indexing model from the issue text.