function-parameter-change functionality, etc.

Designed/implemented a scheme for changing function-parameter values (e.g.,
7-day moving average -> 11-day MA) via the client/server request/response
interface, with much of the logic in MAS_SESSION and with two new classes:
SESSION_FUNCTION_PARAMETER ("proxy" FUNCTION_PARAMETER used to hold and
transmit new user-provided values) and INDICATOR_PARAMETERS_REQUEST_CMD, a
client-request command for obtaining the parameter settings for a specific
indicator.  Still needed is a client-request command for specifying new
values for one or more of these indicators (as well as parallel
functionality for changing parameters for analysis
[MARKET_EVENT_GENERATORs]). MAS_SESSION holds modified function-parameters,
which are used during indicator processing to set the corresponding
parameter values for the target indicator before calling 'process'. This
should allow multiple users to process indicator data without interfering
with each other.

MARKET_FUNCTION: Added 'flag_as_modified' to, when a parameter for an
indicator (MARKET_FUNCTION) has been changed, tell the indicator that it
now needs to be processed again (i.e., processed becomes false).
Implemented in appropriate descendants.

MARKET_PROCESSOR: parameter_unames_unique function to check if the
'unique_name' for each element of 'parameters' is indeed unique.  (Not sure
yet if this can be completely enforced.)

Made EXTENDED_GUI_COMMUNICATION_PROTOCOL obsolete by moving its small
amount of code up to parent, GUI_COMMUNICATION_PROTOCOL.

Changed some 'inherit' clauses to non-conforming inheritance ('inherit
{NONE}...').  Some reformatting: tab -> 4-spaces.
Indicator function-parameter setting - client request, ...

GUI_COMMUNICATION_PROTOCOL: Added two new client-request types:
indicator_parameters_set_request, event_parameters_set_request

MODIFY_INDICATOR_PARAMETERS_REQUEST_CMD: New request-command to modify
function-parameters (e.g., <n> in <n>-period moving average) for a specified
indicator.  It updates the set of parameter-settings (for the target
indicator), stored in the MAS_SESSION, according to the values received
from the client.  (INDICATOR_DATA_REQUEST_CMD then uses the new values,
when it is executed, by calling: 'session.prepare_indicator(indicator)'.)

MAS_SESSION: Two bug fixes:
parameters_for_indicator: Added missing insertion into ind..._map:
+                indicator_to_parameters_map.force(Result, i.name)
prepare_indicator: Wrong order of operands with respect to "or else"
short-circuit:
-                update_occurred := update_occurred or else
-                    update_parameter(param_cursor.item, reference_cursor.item)
+                update_occurred := update_parameter(
+                        param_cursor.item, reference_cursor.item) or else
+                    update_occurred
(bug caused needed (2nd+) update to not occur.)
FUNCTION_PARAMETER-related cleanup

Cleanup after work on (client) requesting/setting function-parameters -
Removed debugging-related code/comments and some experimental/obsolete code.
MARKET_PROCESSOR -> TRADABLE_PROCESSOR

Renamed MARKET_PROCESSOR to TRADABLE_PROCESSOR: The original name is not
the best fit, since this class models tradable items (i.e., an instance of
the class represents a tradable thing, such as a stock [e.g., IBM] or
commodity) rather than a market (where many tradable items can be bought or
sold) or markets.  The prefix "MARKET_" is used in the name of several
other classes, as well; these should probably also be changed in the same
way.

Two assertion-related bug fixes: check statement in the wrong place in
MAS_SESSION; and use of '=' (reference comparison) instead of '~'
postcondition of the make routine of SESSION_FUNCTION_PARAMETER.
Parameter setting for MARKET_EVENT_GENERATORs

Implementation of client requests for retrieving and setting parameter
values for market-event generators (i.e., tradable-data-analysis signal
generators), using common logic for indicators (AKA MARKET_FUNCTIONs, or,
probably in the future - TRADABLE_FUNCTIONs), since both involve setting of
FUNCTION_PARAMETERs (and use of SESSION_FUNCTION_PARAMETERs).  Some
refactoring is needed, since there is some duplicated code that could be
put in, e.g., a shared parent class.  'flag_as_modified' needed to be moved
up from MARKET_FUNCTION to its parent, TRADABLE_PROCESSOR.
EVENT_DATA_REQUEST_CMD needed logic added to call session.prepare_processor
on each MARKET_EVENT_GENERATOR being executed to ensure that the latest
values from any modified parameters were used for the analysis.  Note:
MAS_SESSION.processor_to_parameters_map (used to be called
indicator_to_parameters_map) is now used to look up the function-parameters
for MARKET_EVENT_GENERATORs as well as for indicators (MARKET_FUNCTIONs).
parameter command refactoring; protocol update

Refactoring of the *PARAMETERS_REQUEST_CMD classes to get rid of
duplicated code.  Includes a new parent class to which most of the
shared logic has been moved: PARAMETER_BASED_REQUEST_CMD.

doc/applications/server_protocol_grammar: Filled in the missing specs for
requests/responses for parameter info and parameter setting.  Made a
corresponding change to two FUNCTION_PARAMETER descendants -
SLOPE_FUNCTION_PARAMETER and START_Y_FUNCTION_PARAMETER: The value-type
description ("floating point value") was inconsistent with other
REAL/DOUBLE parameter type descriptions - i.e., "real value".  Defined
param_type_desc (in server_protocol_grammar) as:
"integer value" | "real value".  So "floating point value" had to change
to "real value".
class name change and OBJECT_INFO_REQUEST_CMD

Two tasks completed: class-name change: MARKET_FUNCTION ->
TRADABLE_FUNCTION; and implementation of a new client-request command:
OBJECT_INFO_REQUEST_CMD: Send information about specified indicators and
event-generators to the client.
object_info_request: protocol, *CMD

OBJECT_INFO_REQUEST_CMD - improvements.  Filled in object_info_request
protocol.
OBJECT_INFO_REQUEST_CMD: Completed: html output option.