Address issues raised during code review [RIPD-480]

 - Regenerate Visual Studio project file.
 - Use standardized #define names.
 - Put #define in a central location (BeastConfig.h).
 - Patch a security hole identified by David.
 - Regularize strings going from the Transactor to the journal.
Address most issues from recent code review [RIPD-480]

The simple issues are addressed with this commit.  There is more work to do.

This commit does not address the following review comments:

 o sfSigningAccount must be neither serializable nor legal in a serialized
   transaction.  Find a different solution to returning the SigningAccount
   JSON object in RPC.

 o SigningAccount lacks an STObject template.  Identify where to keep such
   a template, put it there, and use it.  I don't think it belongs in either
   LedgerFormats.cpp or TxFormats.cpp, but I could easily be wrong.

 o Discover how to validate a SignerEntry object using STObject::setType ().
   Use STValidation as an example.

 o Move extensive javadoc from SetSignerList.cpp into a transactors/README.md.

 o There was discussion of changing some TER codes currently returned by
   Transactor::checkSingleSign () and Transactor::checkMultiSign ().  What
   I took away from the discussion is that, in order to preserve existing
   transaction behavior, I shouldn't change those values right now.  Let me
   know if I misunderstood the outcome.

 o Fees and reserves are missing.  In particular, SetSignerList doesn't check
   if the account has enough XRP to bump the reserve count.  Lots of other
   fee/reserve related stuff is missing as well.  I had hoped to postpone
   all fees and reserves work until I got this intermediate commit in place.
   However postponing the work may not be appropriate.

 o "tem" errors are being returned too late in the process.  It is only valid
   to return "tem" codes up through the `payFee` method of the Transactor.
   'tem' codes that are being returned too late need to be identified and
   changed to the appropriate code.

 o There's discussion of changing transactions so they return 'tef' codes
   against an open ledger and 'tec' codes against a closed ledger.  I'm
   hoping that change is beyond the scope of the m-of-n work.

 o On a similar note, if a transaction is malformed we should return a 'tem'
   code only for RPC calls.  Otherwise, if the transaction comes from the
   network, log the error and claim a fee.  I'm hoping this change too is
   outside the m-of-n scope.

I've tried to be diligent, but it's possible I've missed other concerns.
Please let me know about other concerns that I've missed.