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'))