Rename the java components to jTET, and move the package to ca.mcscert.jtet

As discussed, do the various renames.  I'd like to do this once, so I want to get it checked off before causing further disturbances.

As discussed, do the package rename now.  All MATLAB code is adjusted as necessary,
all java tests pass, and the quadratic example continues to typecheck, as
expected.

As discussed, rename Matlab2SMT to jTET.  Matlab2SMT is a bad name for the
java project, and with its imminent removal first rename it to avoid breakage
in MATLAB code.

Matlab2SMT is moving towards being a real library.  Thus delete the useless
App class that makes it look like a library.  Its only useful function can
be done manually anyways.

To comply with MATLAB Central's license policy, change all files to be BSD
licenced.  Also add a LICENCE file to the root of the project folder, to
make it more obvious the code is 3 clause BSD.  The Licence text is copied
from MATLAB Central.

Add in a converter function that converts Matlab 2d grids to the java representaion.
Do to the ugliness of the Matlab system, there a ton of resizes going on. Also,
the code is completely untested, but works in theory.

Add a 2d grid to the java code.  It uses List<> to make the 2d grid itself,
but hides all implementation details, to allow for future modifications.

Update antlr4 version to 4.2.2, and apache commons to 3.3.2.  Also fully
specify all plugin versions.  While the latest should be used by maven,
experience shows this is always the case.  Thus verify everything.

We have files to ignore, so share the ignore file!

Conflicts:
	@GUI/GUI.m

Due to how the matlab grammar was setup, things would break horribly on systems
with case sensitive file names.  This occurred as some elements had names
differing only by case, which both Antlr and Java were fine with, but relied
on the system have case insensitive file names.  Mac/Windows would thus break
in most cases, along with Dropbox.

Fix by removing these names.  I don't use them, and the one useful case is
handled differently, which shouldn't cause issues in the future.

Make sure enumerated types are only emitted once, even when there is more
then one variable declared with the type.  Also fix the generators so they
actually ensure this.

Also, CVC3Generator got some cleanup around the relevant code.

There is no reason to use a HashMap in the test, which makes checking the
result harder.  So, instead just use a LinkedHashMap so the result is always
the same.

Since variable subtypes can depend upon previously declared variables, emit
the variables in the same order as defined.  While some languages may not care,
it is better to be safe then sorry.

Also, since variables are now always emitted in defined order, remove some
excess try .. catch blocks, which were attempting to handle the unknown order.

Add support to SMTLIB and CVC3 to generate enumeration types.

Add anotations to the class so the Fixed Point tests are run preoprly.

The App class only still exists for easy of testing.  But it definitely doesn't
need a test that does nothing useful.

Enumerations need to have a name so the enumerated type can be defined.  Add
the name as a property of type, so generators can get it easily.  Also update
the various users of the type to pass the name in the constructor.

Rename the class to avoid conflicts with new tests being generated.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11089 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Add support for the generators to deal with enumeration types properly, along
with making sure they won't generate output for other types of operations.
Currently only addition is checked.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11088 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

VariableParser now deals with enumerated types correctly, and VariableCollection
exposes the enumerated types as appropriately so that further parsing/generating
will work correctly.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11087 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Add support for both custom and unknown custom types.  For now, all unknown
types are simply treated as reals for generation purposes.  Custom types can
be registered with a particular VariableParser using any previously existing
type.  All the generation code ignores the new type name and continues as
before.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11086 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

If an unknown error is received, treat it as a failure but without sample
values.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11085 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

If an smtlib checker doesn't generate sample values, use an empty array so
the system can handle everything properly.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11084 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

In preparation for enumerations, a more complete handling of variable information
is required.  Thus create a VariableCollection and use it appropriately.  As
much as possible, the VariableCollection is pushed down the stack as much as
possible.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11083 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

VariableParser now needs to store information about custom types (specifically
enumerations).  Thus make parseVariable take an instance now by making it
a method of VariableParser again.  Also change the TET to use a global
singleton (called TET) to store the TET's VariableParser (since the type
information is global to Matlab).

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@11082 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/trunk/TableTool@10907 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10859 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Sometimes when starting up, a previous handle would clash with an existing
handle, causing the TET to fail to load and locking Matlab into a state
where it can no longer exit.  Fix by ensuring on load no previous handle
is ever used, and instead just regenerate all of them.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/trunk/TableTool@10858 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Add parsing and generating support for the exponent operator.  It currently
doesn't support generation over fixed point values, since CVC3 doesn't include
an easy to use function.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10857 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Adds support for the implication operator in PVS (=>).  Matlab's support for
it is questionable, and thus ignored for now.  The operator is supported in
all layers, including generators.

Note that due to matlab not supporting all the operators, GenericGeneratorTest
now uses PVS to parse in its mega expression.  This changed the parsed's
expression's content, and thus the expression changed a little dramatically.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10856 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

For both SMTLIB and CVC3, variable subtypes conditions are now emitted into
the necessary places.  This doesn't directly relate to the PVS support added
earlier.  For now, no proof is done that the subtype has any allowed input,
but that doesn't matter as the table would still be "valid" for no input.
Determining that the connected Simulink blocks have correct typing is not
considered currently.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10855 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The subtype given for variables are now properly parsed into the entire system.
Currently they are not actually used when generating the checker statements.
The expressions are fully parsed expressions, ready for output however.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10854 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Somehow the NotEquals operator fell through the cracks when implementing
all the other operators.  Add it in, along with the necessary tests so it
will round trip the system properly.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10853 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

In order to support PVS style subtype expressions, the system has to be able
to parser such expressions.  To simplify the variable list parse, it simply
extracts the PVS expressions as a single token, unprocessed.  While requiring
more parsing work for the subtype expression, it avoids the necessity of
changing the parser in the future should a new subtype language be used.

As part of this change, the variable list parser's lexer became to complicated
to be expressed in Antlr's combined grammar format.  Thus split it out.
Everything works the same as before from an API point of view.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10852 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since any parser will have to test itself against a variety of operator, make
life simple and have one set of tests for all operators.  Also remove as much
code duplication as possible, by having one generic method that takes an operator
(as a String) and a parse function that handles calling the parse function
and compares the result as appropriate.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10851 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The subtypes given in tables are given in PVS syntax.  To use these in other
languages, the TET needs to parse PVS expressions.  Note that this parser
is very basic, and only handles the bare minimum needed.  It only handles
basic Math expressions, similar to Matlab.  It doesn't do /= yet, due to missing
support further down the stack.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10850 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

The code to find the operation for a given text string was hidding in the
*Operation enumerations.  Move this code into MatlabParser, as it isn't
reusable as many languages use different symbols.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10849 57e6efec-57d4-0310-aeb1-a6c144bb1a8b

Since all expressions are in fact general pupose expression, and not tied
to Matlab in the slightest, avoid calling the classes as Matlab*.  No actual
functional change is required for this.

git-svn-id: https://groke.mcmaster.ca/svn/grad/colin/branches/TableTool_javization@10848 57e6efec-57d4-0310-aeb1-a6c144bb1a8b