Wide-reaching fix for the problem that the AVerificationResult Argument of the auto-generated SubmitChanges Methods of a Typed DataSet were not reliable:
* Changed the implementation of the SubmitChanges Methods in TypedDataAccess.cs so that they no longer return AVerificationResult Arguments *at all*. That was achieved by no longer wrapping Exceptions into TVerificationResult objects, instead we now simply let the Exceptions happen. That is cleaner and in that way it is much less likely that such Exceptions will go unnoticed, which was possible before if the caller (or the caller chain) accidentally discarded the AVerificationResult that was returned by those Methods!
* That allowed for the change that the auto-generated SubmitChanges Methods of a Typed DataSet no longer have a AVerificationResult Argument *at all* (those changes are in DataSetAccess.cs), and this fixes Bug #721.

Those changes necessitated wide-reaching implementation changes across the OpenPetra codebase, which are part of this commit. As much as possible those have been thought through carefully, though the committer can not know about all the details of all the call chains of the code that was affected by those changes...

All the code compiles 
The NUnit Tests and also the Main Menu Nunit Tests pass.
Follow-up from last commit: Further wide-reaching change to the auto-generated SubmitChanges Methods of a Typed DataSet: remove boolean return value and make these Methods 'void Methods'.
* As a result of the last commit, these Methods always returned TSubmitChangesResult.scrOK, which means that the caller was no longer able to distinguish whether these Methods failed or worked - this is by design of the previous change where the TTypedDataAccess.SubmitChanges Methods were changed to no longer return true or false, but to throw an Exception in case an error occurs (or rather, just let the Exception happen).
* All code segments that call auto-generated SubmitChanges Methods of a Typed DataSet now no longer check whether these Method calls were successful. This simplified the program logic in quite a few places. 
* As the auto-generated SubmitChanges Methods of a Typed DataSet are now 'void Methods', the only way to handle error conditions that can arise because of a call to such Methods is Exception handling - either directly in the Method where such a Method gets called, or further up in the call stack. Should such an Exception not get handled then this would lead to an 'Unhandled Exception', which should be avoided, of course. However, that is still better than a potential loss of information that could occur before in case the result value of calls to auto-generated SubmitChanges Methods of a Typed DataSet wasn't inspected, and/or if the out TVerificationResultCollection was not evaluated or not appended to a local or Argument-passed-in TVerificationResultCollection!!!

Those changes necessitated wide-reaching implementation changes across the OpenPetra codebase, which are part of this commit. As much as possible those have been thought through carefully, though the committer can not know about all the details of all the call chains of the code that was affected by those changes...

All the code compiles.
The NUnit Tests and also the Main Menu Nunit Tests pass.
Changes to custom Exception Types:
* Introduce Base Exception Classes for OpenPetra: EOPException, EOPAppException, EOPDBException. By this it is possible to catch and handle Exceptions by catching only some types of exception we are interested in in certain conditions.
* Access.cs: no longer throws System.Exception Type Exceptions, but only Exceptions of Type EOPDBException where it threw System.Exception before.This allows us to catch Exceptions coming from the DB Access Layer and to handle them specifically. (test.cs already utilises that).
* TypedDataAccess.cs: no longer throws System.Exception Type Exceptions, but Exceptions of Type EDBSubmitException and EOPDBTypedDataAccessException where it used to do that. This allows us to catch Exceptions coming from the the Typed Data Access Layer and to handle them specifically.
* Types.cs: moved custom Exceptions out of that file and into Exceptions.cs and Exceptions.Remoted.cs.
* All other Exceptions:
** Derive from one of the appropiate new Base Classes and no longer from AppliationException.
** Added constructor with no Argument and constructor with Argument signature 'string, Exception' where they weren't present yet so Exceptions without messages and Exceptions with messagesna and InnerExceptions can now be passed on with all our custom Exceptions.
** Fixed Serialization in a few cases (those Exceptions would not have been serialized correctly using .NET Remoting).
** Standardised XMl Code Documentation, guided by MSDN documentation for System.Exception.
Follow-up from last commit: Changes to even more custom Exception Types.
Change SubmitChanges Method and all its overloads so they no longer return a boolean value, which is only possible because of  all the previous changes in this Branch.
Wide-reaching change that concludes the work where our *Access.SubmitChanges Methods are refactored to no longer return a bool value and also no longer an out TVerificationResultCollection:
* Earlier changes in this Branch allowed me to change the auto-generated *Access.SubmitChanges Methods of a Typed DataTable into 'void Methods' that no longer return a bool value. The introduction of a new Typed Exception, EVerificationResultsException, allowed me to change that these Methods no longer have an out AVerificationResult Argument *at all* (those changes are in DataAccess.cs).

* All other changes in this commit reflect the necessary changes that followed from that single change! In many cases the changed code is considerably simpler! In some cases I have also added Exception handling where it wasn't present to ensure a DB Transaction would be rolled back in case an exception (e.g. EVerificationResultsException) is thrown, in other cases where there was Exception handling in place but where I deemed it not solid enough I have improved it. I have also added many logging statements in Exception Handlers while I was there anyway...
Fix a bug that I accidentally introduced in Method 'SaveUserDefaultsTable' while refactoring... this was causing a never-ending loop, resulting in too many 'INSERT' statements being issued.
TTypedDataAccess Class: Make sure that any calls to DBAccess.GDBAccessObj.ExecuteNonQuery that would return 0 (which signalises that there was no row affected) will no longer go unnoticed - I am throwing the Typed EDBSubmitException in such cases now.
merge from trunk. 
Had conflicts in 3 files which were caused only by renaming 'Gift Receipting' to 'Gift Processing'.
Fix an XML Comment on Method TVerificationHelper.IsNullOrOnlyNonCritical that was syntactically incorrect (pointed out only by the mono compiler).
Partner.cs: Remove a line of 'unreachable code' (pointed out only by the mono compiler).
Main.cs, CommonNUnitFunctions.cs: Fix further XML Comments on Methods that were syntactically incorrect (pointed out only by the mono compiler).
Common.Posting.cs: Fix a bug that I accidentally introduced in Method 'CreateARecurringBatch' while refactoring... I accidentally removed a whole line of code where I should have modified it instead...
Change and improve an Exception that has to do with DB Concurrency.
Fix a XML Comment on a Constructor of EDBConcurrencyException.
Improve DB Exception reporting.
merge from trunk
merge from lp:~christian-k/openpetraorg/dev_20140107_DataAccess_Change_Error_Handling.