add support for listing accounts and currencies

This change does two things: First, it switches the fxBot to make use of
the OptionParser class which simplifies command line parsing
significantly. Second, it introduces a first set of options. The main
ones are --list-accounts which lists a user's (sub) accounts and
--list-currencies which returns a list of currencies the user is allowed
to trade.
introduce new class Program

Since the beginning a lot of functionality got added to fxBot.py and by
now it is hard to get a quick overview. This change refactors the code
by introducing a new class Program which provides methods corresponding
to actions as specifiable through the different command line arguments.
introduce __queryWidths method

By now we have two functions that print data in a tabularized format
with variable column widths. To simplify creation of such a tablular
view and not require every new user to reinvent the same error-prone
mechanism, this change introduces a new function __queryWidths that
automates the process a bit more.
introduce Currency class representing a single tradeable instrument

This change introduces a class new class called Currency that represents
an instrument tradeable at the market.
use __queryWidths function for printing of historic data

This change uses the __queryWidths function to also columnize the output
of historic data and the calculated exponential moving averages. This
way we no longer have to manually hardcode a fixed amount of spaces
before each column title.
add EventStreamer and RateStreamer classes

This change adds two new classes to the project: EventStreamer can be
used to subscribe to a stream of events coming from the OANDA server.
Events include the triggering of stop losses, the cancelation of an
order and more. RateStreamer on the other hand subscribes to a stream of
price changes for a set of instruments/currencies. This way we can get
frequent updates on the current prices and can react in a timely manner.
register signal handler to tear down gracefully on Ctrl+C

When terminating a streaming program abruptly we often see a backtrace
indicating an unhandled interruption in some HTTP connection.
This change registers a signal handler for SIGINT which is sent (among
others) when a user presses Ctrl+C. In this case we first disconnect the
streams and then exit normally.
As a bonus, this change also introduces a new command line parameter:
-v/--verbose. This parameter is meant to increase the verbosity of
output throughout the program.
use logging module for logging of various events

With this change we take a step away from using print() invocations to
convey diagnostic information to users. Instead, we use the logging
module which provides features such as redirection of the output to
various destinations as well as different log levels.
handle SIGTERM signals along with SIGINT

A previous change installed a custom signal handler to handle SIGINT
signals which are usually sent to a program when Ctrl+C is pressed. A
less common way to shutdown a process is to directly send SIGTERM to it
on which it can react.
This change also registers the same signal handler introduced previously
for handling SIGTERM signals and correctly shutting down the
infrastructure.
introduce ThreadedStreamer class

The current approach of creating and polling on event/tick streams for
new data from the main program object does not work correctly under all
circumstances. For starters, waiting on the streams is a blocking
operation which means we can only wait on one stream (a select-like
mechanism is not available). In addition, signal handling is screwed up
once the main thread is waiting in a blocking system call.
For these reasons, we need to perform the waiting for new data on the
two streams in threads running concurrently to the main thread. This
change introduces the ThreadedStreamer class that moves the
functionality of OANDA's Streamer object into a separate thread. For
transfer of data (i.e., work items) between the stream threads and the
main thread, a queue object is used.
introduce worker class to handle work asynchronously

Python's signal handling infrastructure is really a pain. To the best of
my knowledge it is impossible (without directly interfacing with
operating system APIs not directly accessible from within Python) to get
correct signal handling when blocking system calls are in use. Although
Python provides the set_wakeup_fd() functionality which can be used to
unblock a thread waiting in a poll or select call, doing so in
conjunction with higher level APIs is impossible (because one cannot
hook into the lower level system calls used).
To that end, the main thread must not execute any blocking system calls
if a program is to react to signals in a timely manner. This change
introduces a Worker class that pushes the waiting for and processing of
events previously done in the main thread into another thread. Using
this mechanism we can now finally get correct signal handling while
still only waking up when necessary.
push all actual work functionality into the worker

Now that the worker is in place, we can also push more of the event
processing into this object away from the streaming threads. This way,
the worker is the central point of processing and forms the starting
point for all event based logic.
merge duplicate functionality from rateStreamer and eventStreamer

By now more work got moved into the worker and it turns out that
rateStreamer and eventStreamer share the same implementation of the
on_success() and on_error() functionality.
This change moves these methods into the ThreadedStreamer class.
modify the format of the logging output

This change modifies the format of log output as logged using the
logging module. Previously (using the default format), no timestamp was
contained in the output and the component/logger to which the request
was issued was printed before the message.
With this change we use a format of the form:
  "<date> <time> <log lvl> <msg>"
where date and time are in a user readable format and log level is one
of [DD], [II], [WW], [EE], [XX], representing the default log levels.
adjust --list-currencies option to also print generic currency name

With this change the output produced when the --list-currencies options
is specified now also includes the undecorated instrument name as
accepted by the OANDA APIs. The expectation is that these names will be
used throughout the program rather than the actually displayed names.
introduce --currencies parameter

This change introduces a --currencies parameter that accepts a list of
currencies. In this first change, this list of currencies can be used to
influence the output as produced by the --list-currencies option: only
currencies supplied will be listed in this case.
Later on, the list of currencies will influence other functionality as
well.
swap return tuple values of return of currentPrices

In most other applications the ask price is displayed before the bid
price. In addition, 'ask' is lexicographically smaller than 'bid' in
most locales ;)
Such being the case, this change adjusts the currentPrices() method to
return a tuple (ask, bid) rather than the other way around.
introduce Strategy interface

This change introduces a new abstraction: a strategy. A strategy is
invoked periodically by some executing entity and can decide whether to
file a new trade, close an existing one, or simply do nothing right now
and log the request.
The Strategy interface defines the basic set of methods all strategies
have to provide.
introduce a watchdog class

During testing it could repeatedly be witnessed that sometimes the
stream tracking the current prices of currencies just delivers nothing.
This case cannot easily detected since no error is reported (my
suspicion is that for some reason the server does not want to serve our
stream).
This change introduces a watchdog thread that periodically wakes up,
checks if no price updates have been received and in that case
explicitly queries the prices and creates a new tick. Note that the
checking whether or not price updates have been received is still to be
done. For now, sending a tick happens unconditionally.
Using such a watchdog also paves the way to providing an option to not
using the streams at all, which might be preferable under certain
circumstances.
reorder initialization/destruction of objects in Program class

The initialization/destruction sequence of objects in the Program class
does not have the correct order. Fix this.