STL Support

[jdeans289]

This is one of the main goals of this project. We need to have fully integrated design level support for STLs, nothing tacked on or out of place.

Some thoughts:

• Namespaces should be implemented before this. All of the STLs we're going to care about will be in the std:: namespace, and we shouldn't be worrying about that while thinking about namespaces.
• Templates will also need to be supported.
• They will all be a BaseType.
• I think it's possible that we can support all STLs by adding 2 additional DataType subclasses - a variable length list and a pair (or is a pair a CompositeType with two members - first and second?). I will have to think a lot about how to handle the different kinds with different operations - maybe just using iterators?
• Each element of an STL will probably have to have its own alloc info. I need to look into how to define custom allocators - this seems very doable.

[jdeans289]

STL support for sequence types implemented with #38 !

Some notes:

• I did not end up going the route of using a custom allocator, and I don't think it's necessary to do so. First of all, doing so would make it clunkier for users to use STLs in their code, since they would need to instantiate them with this allocator. Maybe that could be solved with some clever preprocessing, but if it's not necessary I'd rather not.
• The purpose of using a custom allocator would be to give the memory manager awareness of where each element of the STL lives in memory. The main reason that we need this is to enable pointers to elements inside an stl, but I DO NOT THINK WE SHOULD SUPPORT THIS.
  • STLs can reallocate their memory when the size changes! (not all types, but most). I think that allowing our users to keep pointers to things inside an STL is just asking for trouble and unsafe practices.
  • The getElemAddresses() function in SequenceType uses normal STL iterators (by using templates) to get the addresses of every element. I'll need to enforce that this is always retrieved when it is needed, and not stored anywhere, but I think this is sufficient for the functionality that I want. This is less of a break of the STL abstraction than poking around with the memory manager, so I like it better.
  • As long as the root of the STL container is registered with the memory manager, we can get what we need from it. Good enough.