Add ReleaseSafe, Debug, ReleaseFast options

[czgdp1807]

We should provide the following command line options so that testing by hand with lpython is easier,

1. --safe - Basically debug mode by hand. Will automatically enable options like, --enable_bounds_checking, --check_integer_overflow (not sure if it is already there), --raise_key_errors (isn't there but to be added), --memory_safety (isn't there but I mean ensures memory safety in the generated code) if --safe is passed in the command line. Should be turned on by default in my opinion.
2. --fast --safe - Keeps safe check enabled but tries to optimise as much as possible. See, Clarify the "LPython contract" in the docs #1139.
3. --fast - No safety checks enabled in this case. The code is as high performance as possible.

cc: @certik

[certik]

Yes, we need that. The --safe option will enable all checks needed to ensure the code can never segfault or have undefined behavior:

• bounds checking (--enable_bounds_checking)
• integer overflow
• dict key errors
• dangling and null pointer dereference (including making sure the array is allocated before usage, etc.)
• stack overflow (too large stack arrays, too deep function nesting, infinite recursion)
• ...

There are probably other checks needed for this.

[certik]

The --fast --safe option (ReleaseFast) is interesting, as one could imagine doing all kinds of approaches like eliminating bounds checks if they are not needed, such as in:

for i in range(size(A)):
    A[i] = i

Which can't be out of bounds by definition. And other similar ideas, like checking before the loop, and not checking inside the loop, etc.

[Thirumalai-Shaktivel]

Should we enable this runtime check only in Debug mode only. Should ReleaseSafe also contain it? ReleaseFast shouldn't do this runtime check I think. What do you say?

Yes, I think ReleaseFast should not have this check, but ReleaseSafe and Debug modes should have it. We can implement this later as well.
#1180 (comment)