Payload Implementation

[hepengfe]

This PR partially implements #810

Description of changes

• implement basic adding of Payload in DataPack and DataStore
• implement Payload generic class with its subclasses for different modalities such as text, audio and image.
• Payload can holds loading method and load path(assigned in reader), and they can be used together to achieve lazy loading in processor (rather than reader).
• modified example of audio reader to show how lazy loading works in the new design.

Possible influences of this PR.

• modularize loading/caching data of different modalities.
• keep data independent from data ontology classes from the perspective of loading/caching such that we make sure data ontologies are lightweight

Test Conducted

Describe what test cases are included for the PR.

[hepengfe]

For audio and image data, we don't want to import third-party package directly in the payload class so I keep a loading interface (an abstract method loading_method) such that users can/must customize the loading method.

I rewrote the AudioReader into SoundfileAudioPayload example here https:/asyml/forte/pull/828/files#diff-0a7626d45acb22318a269b5ece6049d603ad6326f8108cda7a0ed2dbc3978440. In this example, user import third-party package in the loading_method and customize their own payload class.

[hunterhector]

For audio and image data, we don't want to import third-party package directly in the payload class

True.

so I keep a loading interface (an abstract method loading_method) such that users can/must customize the loading method.

I am considering whether this is a good idea since that means users will have to write customized code in the ontology class files (which are generated). This will create a few problems:

1. Future generated code would overwrite this.
2. The implementation cannot be passed along with a JSON spec file only.
3. If forces someone to use one single function to do the parsing, which might be a small problem.

Actually, we don't have to make the ontology this complex, the Payload ontology only needs to store the data, but it doesn't have to know how to parse the data. Like in the text processing part, we put most of the work to the reader.

Imaging the HTMLReader, you can consider HTML texts are special texts with customized loading methods, but we won't put the loading logic in the entry.

I would suggest the following:

1. define payload entry to store what data will be stored/cached
2. define a metadata ontology to specify the data formats (like JPEG)
3. write some readers, which will load the payload depending on the metadata

Note that we are not experts in image formats right now, so for steps 2 and 3, we can create examples first, and not make them core library code. Once we fully master or get comfortable with certain data types (I think it is possible for easy data types like images stored as NumPy matrices), we can move more to the library core.

[hunterhector]

I remember clearly I requested to install enum package (https://pypi.org/project/enum34/) for compatibility issues, but this is not really addressed. requirement.txt is not enough, it must be in the setup.py. @mylibrar @hepengfe

[hunterhector]

This is not a solution. We cannot import items that are generated back to the source code. This doesn't make sense.