[Code Cleanup/VA/Events] Modified the generateSampleEventModel() method signature in events so that the first argument is always a Model_TriggerEvent.  This allows sample events to be based on the trigger and Virtual Attendant parent.  For example, some event types always target the VA itself.
[Code Cleanup] Removed some unused code
* [Virtual Attendant/Simulator] Public worklist variables in Virtual Attendant behaviors can now be tested properly in the simulator.

[Code Cleanup/Virtual Attendants] Added a reusable Model_TriggerEvent->formatVariable() method.  This is used by both the simulator and the REST API.
* [Virtual Attendants/Actions] The 'Schedule behavior' and 'Run behavior' actions in Virtual Attendants can now include placeholders in the parameters being passed to the other behavior.
* [Virtual Attendants/API] Implemented '/rest/va/list.json' in the Web API for retrieving the list of Virtual Attendants that are visible to the current worker.  This can include an 'expand' parameter with the option 'behaviors' to list all of the defined behaviors.

* [Virtual Attendants/API] Implemented '/rest/va/123.json' in the Web API for retrieving the a particular Virtual Attendant.  This can include an 'expand' parameter with the option 'behaviors' to list all of its defined behaviors.

* [Virtual Attendants/API] Implemented '/rest/va/behavior/123/run.json' in the Web API for running a 'Custom API request' Virtual Attendant behavior.  This provides a standardized way for external applications and services to communicate with Virtual Attendants in Cerb.  For example, a Campfire Bot can listen for messages in a chat room and relay a specific pattern (e.g. "@Cerb do something") to a specific VA behavior through the Cerb API.  The response is a dictionary of all the behavior's values after running, including public and private variables.  If a behavior retrieves a list of tickets, then their details will be available in the response for use outside of Cerb.
* [Virtual Attendants/API] Added a new 'Custom API request' event to Virtual Attendants.  This can be utilized by app-owned and worker-owned VAs.  These behaviors work similarly to macros, except they are only triggered through the API from external apps and services.  This allows for interaction with Virtual Attendants through mobile text messages, email, instant messages, Campfire/Hipchat, mobile applications, browser plugins, etc.  Custom API request behaviors always target the owning Virtual Attendant, and they provide an 'Add to API response message' action that appends text to the '_response' value of the API response.  Using the '_response' value is optional, but it provides for generalized interaction with Virtual Attendants through the API.  For example, an iOS app could display a list of all Virtual Attendants and their API-enabled behaviors.  Running any behavior could prompt for its public parameters, and the response message could be displayed.  It's also possible to use the 'custom placeholder' action for additional outputs.
* [Virtual Attendants/API] When a Virtual Attendants dictionary is converted to an array (e.g. for use by the Web API), any nested dictionaries will also be converted to arrays.  Previously, if a behavior contained extra dictionaries (e.g. a list of records from a worklist search), it would return the IDs of those records but not their values.
6.5-dev checkpoint