make `.get()` and indexing (`[]`) more pythonic

[keighrim]

Because

At the moment, various classes in mmif.serialize package implements .get() and .__getitem__() methods, but their behavior are

1. not consistent across classes
2. not well-documented in one place (they all have decent docstring, but no aggregate of them exists)
3. not so "pythonic" in that their behavior often deviates from standard python get and __getitem__ methods in built-in classes.

Done when

• all existing (de-)serialization classes are categorized into "dict-likes" and "list-likes"
• inspect current implementation of get and __getitem__ for each
• update, if necessary, the methods to match those of python dict's and list's

Additional context

This proposed change will vastly break compatibility of the SDK to existing CLAMS app code, so we need a version marker that can mark this breakage. (#293 )

[keighrim]

From @bohJiang12 's comment in #304 ,

dict-like:
- Mmif: a class for MMIF objects
- MmifMetaData: a class for MMIF metadata
- View: a class for MMIF view
- ViewMetaData: a class for MMIF view metadata
- ErrorDict: a class for a specific view that contains error
- ContainsDict: a class for View's 'contains' field
- Annotation & Document: a class for MMIF annotation and document
- AnnotationProperties & DocumentProperties: a class for MMIF annotation properties
- Text: a class for Document's text field

list-like:
- DocumentsList: a class for a list of Document objects
- ViewsList: a class for a list of View objects
- AnnotationsList: a class for a list of Annotation objects

---

I actually disagree on View and Mmif classes being dict-like. Instead I think View is simply a delegate for AnnotationsList, and Mmif for DocumentsList + ViewsList, hence both are list-likes.

Then, we have primarily two list-like classes View (≈AnnotationsList) and Mmif (≈DocumentsList + ViewsList), but for both, the elements of the underlying data structures are not just indexed by their order (hence integer), but individually assigned with non-overlapping (at least at the same level) string-ID's. That said, I'd like to propose we implement

dict-likes

• get = __getitem__ = slicing ([]): all take a string key, and return corresponding element object value under that key.
• specifically for get implementation, we can allow the "default" value (as the second argument) if the key not found.

list-likes

• slicing ([]): takes an integer and returns N-th element in the list.
• get: takes a string ID and returns corresponding element in the list.
  • no "default" value passing
  • for Mmif, if the argument string is in V:A format (a "long-form" of annotation ID), do two-level search
• no internal implementation of `getitem dunder method.
• since both Mmif and View don't allow arbitrary/additional properties, all other fields should be accessible via class attributes. (e.g., view.metadata should give the metadata object, instead of view.get('metadata'))

[keighrim]

After working on this for a while, i actually came to the same conclusion with @bohJiang12 , in that Mmif and View classes are better be in "dict-like" group.
So the plan now is

Class Type	__getitem__	get(key, default)
Pure List-like DataList, DocumentsList, ViewsList, AnnotationsList	[int] or [slice] Positional access only TypeError for strings	❌ Remove completely (Python lists don't have .get())
Dict-like MmifMetadata, ViewMetadata, Annotation, Document, ContainsDict, etc.	[str] Key-based access KeyError if not found	✅ get(str, default) Safe access Returns default instead of raising
Containers Mmif, View	[str] Multi-level ID search Searches collections by ID	✅ get(str, default) Inherited from MmifObject Safe high-level access

Currently there's get method implemented for list-like classes, so I will add deprecations warning to those classes.