Adds changes for sequence data type

[desaikd]

Issue #, if available:

Description of changes:

This PR works on adding new model changes following up on #135. This Pr only contains changes for Sequence. This PR disables Rust support until the entire functionality for the new model change is supported and uses feature branch new-model-changes as target.

List of changes:

• Generator changes:

  • Adds build_wrapped_sequence_from_constraints which is used for constructing named sequence data type as data model.
  • Adds build_sequence_from_constraints which is used for constructing nested sequence data type as data model. (Doesn't have a name)
  • Adds is_nested flag in convert_isl_type_def_to_data_model_node which can be used to either call wrapped sequence or sequence ADT construction.
  • Modified sequence construction to move the common logic at the beginning of the method.

• Model changes:

  • Changes Sequence and WrappedSequence ADT to represent the underlying sequence type with base_type and its name with name field.
  • Adds doc comment changes for the same

• Adds templates changes for java/sequence.templ

Generated code:

The generated code still stays the same only the template changes to use the new model. (Only added sequence files for checking this change, other files remain same)

Generated Java code can be found here.

Tests:

• Adds tests for ISL to model conversion.
• Modifies roundtrip code gen tests for sequence test cases.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[popematt]

Are we going to have to create corresponding Wrapped* variants for all of the non-wrapped variants? Why/why not?

[desaikd]

No. I think its in general there are only 3 types structure, sequence and scalar. Where only nested structure would have a name but scalar and sequence would not have name. Hence to separate out whether they are named or not I have them as a separate variant. I think having them separate allows us to perform specific operations for these types which will be stored as property instead of entirely different class in the generated code.

e.g. For below ISL:

type::{
   name: my_type,
   fields: {
        foo: {type: list, element: string} // this will not create a new nested class in the generated code
   }
}

Here's the generated code in Java:

class MyType {
   private java.util.ArrayList<String> foo;
   ...
}

whereas for structure type like following:

type::{
   name: my_type,
   fields: {
        foo: {
           fields: {
               bar: string
           }
        } 
   }
}

Here's the generated code in Java, which creates a new nested type for this nested structure:

class MyType {
   private NestedType1 foo;
   ...
   
   class NestedType1 {
       private String bar;
       ...
   }
}

[zslayton]

Approved pending changes to the issues Matt raised.