Deprecate direction parameter for framing Edges from FramedGraph.frame

The FramedGraph.frameEdge methods have a Direction parameter to
define which side of the frame is the domain (source) and which side
the range (target) of the framed-edge. This is confusing, because
an edge already has a direction that defines source and target of the
frame.

Moreover, it seems of little use to be able to change the direction
of a framed edge at runtime: The framed type has a natural
direction (e.g. Knows vs. IsKnownBy, or Created vs. IsCreatedBy).
This is most apparent when both sides of the edge are of different type
(e.g. Person - Created - Project, vs. Project - CreatedBy - Person).
Passing the wrong direction at runtime will just result in a
ClassCastException.

The direction parameter also makes it hard to generalize the framing of
elements, because for edges you need additional parameters. E.g. it
will be very easy to implement edge-support for GremlinGroovy
annotations (currently GremlinGroovy only supports vertices as input and
output), once the direction parameter is gone.

The direction parameter is only used by the @Domain and @Range
annotations.

Starting from 2.4.0 the direction parameter is not available for
framing edges. Instead, the direction of the framed edge defines the
(natural) domain and range of the frame.

This commit deprecates the FramedGraph frame/addEdge/getEdge/getEdges
framing methods that take a direction parameter, and adds the methods
that don't have a direction parameter.
Revert to the old behavior for Domain/Range annotations, introduce
Initial and Terminal annotations for edge framing

Following the discussion in #65 the Domain and Range annotations are now
deprecated. Instead of altering their semantics, the new behavior
is activated by using Initial/Terminal instead of Domain/Range
Improve CHANGELOG description of changes for edge framing
Merge branch 'gjdev-edgedir3'

Conflicts:
	CHANGELOG.textile