Add Acc debugging functionality similar to Debug.Trace

[ivogabe]

Description
To make it easier to debug Accelerate programs, this PR adds functionality to inspect intermediate values of a computation, similar to what Debug.Trace provides for Haskell programs.

-- | Outputs the trace message to the console before the 'Acc' computation can proceed
-- with the result of the second argument.
--
atrace :: Arrays as => String -> Acc as -> Acc as
atrace message = atraceArray message (Acc $ SmartAcc Anil :: Acc ())

-- | Outputs the trace message and the array(s) from the second argument to the console,
-- before the 'Acc' computation can proceed with the result of the third argument.
--
atraceArray :: (Arrays as, Arrays bs) => String -> Acc as -> Acc bs -> Acc bs
atraceArray message (Acc inspect) (Acc result) = Acc $ SmartAcc $ Atrace message inspect result

-- | Outputs the trace message and the array(s) to the console,
-- before the 'Acc' computation can proceed with the result of
-- that array.
--
atraceId :: Arrays as => String -> Acc as -> Acc as
atraceId message value = atraceArray message value value

-- | Outputs the trace message and a scalar value to the console,
-- before the 'Acc' computation can prroceed with the result of the third argument.
--
atraceExp :: (Elt e, Arrays as) => String -> Exp e -> Acc as -> Acc as
atraceExp message = atraceArray message . unit

Note that arrays are printed in their internal representation (using 'ArraysR'), which causes that tuples or custom data types are shown differently. In the current setup it is not possible to show them in the surface representation, as we do not have the link between those two representations. This link could be stored by storing the Arrays type class or a conversion function in the Atrace constructor, but then we wouldn't be able to implement lifting to Template Haskell any more.

The debugging is currently only supported on Acc-level. You can thus only inspect values during an Acc-computation. It is not yet possible to inspect values within Exp-context, which we may want to add in the feature. For GPU backends this may be more difficult to add though.

Motivation and context
This change makes it easier to debug Accelerate programs, which has been requested often.

How has this been tested?
I tested this in my Delta stepping implementation.

Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist
Go over all the following points, and put an x in all the boxes that apply. If you're unsure about any of these, don't hesitate to ask. We're here to help!

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[ivogabe]

I still need to make the accompanying change for the LLVM backends.

[ivogabe]

The PR for accelerate-llvm is now also open: AccelerateHS/accelerate-llvm#66

[tmcdonell]

I wanted to move this into its own D.A.A.Debug.Trace module for symmetry, but realised we already took that name so such reorganisation will be future-Trev's problem ¯\_(ツ)_/¯

[tmcdonell]

anyway, thanks! this should be super useful (: