Add dtype to SemanticPointer and fix repr

[arvoelke]

Motivation and context:
This is an experimental feature request (split off from #243 and rebased onto master), that allows one to experiment with other data types for semantic pointers, such as np.complex64.

Full support is not provided. The intended scope is for offline algebraic manipulation of SPs. In the future, one might wish to support complex types in the neural implementations as well.

Interactions with other PRs:
Assuming #243 is merged first, then this would need to be rebased such that dtype also passed into the new methods for SP fractional binding. Also changes may be needed to allow fractional_bind to return a complex SP if the datatype is complex.

How has this been tested?
Unit tests pass, but new unit tests are needed (see 'Still to do').

How long should this take to review?

• Quick (less than 40 lines changed or changes are straightforward)

Types of changes:

• New feature (non-breaking change which adds functionality)

Checklist:

• I have read the CONTRIBUTING.rst document.
• I have updated the documentation accordingly.
• I have included a changelog entry.
• I have added tests to cover my changes.
• I have run the test suite locally and all tests passed.

Still to do:

• Unit test algebraic manipulation of complex SPs
• Check all of the places where semantic pointers are created (e.g., vocabulary.py)
• Add changelog entry

[arvoelke]

Missed another interaction with #243: for the chosen VTB fractional binding + nondegenerate vectors there was also this unit test that was stripped out:

    # satisfies translational properties as long as the intermediate results
    # are allowed to be complex
    x_complex = SemanticPointer(v, algebra=algebra, dtype=np.complex128).nondegenerate()

    assert np.any(np.iscomplex((x_complex ** 0.5).v))
    assert np.allclose((x_complex ** (-0.5) * x_complex ** 2.5).v, (x * x).v)

but I'm not sure if there's a good reason to have this combination of features. Just stating this for reference.