Adding integrator options and velocity options

Simple string settings that are explained in the code

%---
integrator Options:  api-leapfrog, inline-leapfrog, inline-verlet
%---

api-leapfrog uses hb constraints.  inline integrators do not (for now).
    timestep for api=1fs         < beta dH >~=0.05 (leapfrog only)
    timestep for inline=1/2 fs   < beta dH >~=0.05 (both vv and leapfrog)

Timings:  context creation in update_ncmc:  0.06s

(approximate) Timings for one lambda loop:

setting 1) (n_work_steps,n_prop_steps)=(100,1)
integrator         time
api-leapfrog       2.2
inline-vv          9.4
inline-leapfrog    9.5

setting 2) (n_work_steps,n_prop_steps)=(1000,1)
integrator         time
api-leapfrog       20.9
inline-vv          94
inline-leapfrog    93

setting 3)(n_work_steps,n_prop_steps)=(50,20)
integrator         time
api-leapfrog       21.5
inline-vv          21
inline-leapfrog    9.5

To generate these calcs, run with mc_titration(...,debug=True),
and it will pause after one lambda loop.

The take homes are:

  -context creation is much faster than I thought

  -the api integrator beats inline for pretty much any setting I can
   think of.  The large number of lambda steps (1000) do not slow this
   calculation down significantly.  For any python version, it should be
   used *exclusively*.  We can keep the inline integrators to help us think about
   how the C++/CUDA implementaton might look.

  -the leapfrog and vv integrators perform similarly well.  I don't think that
   incorporating constraints will improve performance, but it might be nice to
   have it in there.

%----
velocity options:
%----

  now only changes velocities upon acceptance (reverses or randomizes).
  I have not tried to evaluate performance on this yet.

To Do Next:
     - clean up titration state output.
     - finish xml loader.
     - set up protocol for capped-zwitterion free energies.