Combine dct and qct interfaces

[cval26]

Closes #34 item 1; also related to #9, #22. See #34 for the motivation behind this PR.

This PR combines the interfaces of dct(x,n) and qct(x,n) families of procedures under one interface dct(x,n,type), where type=1,2,3 is the type of DCT to be performed. This brings the modern interface of DCT in line with current DCT terminology (see the Wikipedia article for more details).

For the new dct(x,n,type) interface, I set type=2 as the default value. I have no personal preference over the default value, but it seems that DCT-2 is the most popular DCT because of its widespread use in data compression. This is also the default DCT used in SciPy and Matlab, so I believe it makes sense that we use it too.

All tests run successfully in my local build.

[cval26]

This PR is ready for review, @zoziha. The main changes are:

• combined dct(x,n) and qct(x,n) under one interface dct(x,n,type);
• combined all previous dct/qct tests and added a few more;
• updated and improved the DCT-related documentation, so that it's clear which DCT type each procedure corresponds to.

The diff for the documentation file fftpack.md is rather large, because I had to change the heading levels throughout the document to make the headings consistent. Most of the meaningful changes are in the DCT section. The file is more easily viewed rendered in an editor.

[zoziha]

Thank you @cval26 . This looks good.
I leave you with a few suggestions, which may not be necessary.

[certik]

@jacobwilliams can you please review this?

[cval26]

@jacobwilliams any updates on this?

[zoziha]

According to previous experience, the number of reviewers of fftpack is often insufficient, which is a practical problem. Since the dct interface is a high-level interface, this PR does not change the low-level interface and maintains the unity with the scipy.fftpack.dct interface, and the code passes the test.

I also compared the result of dct(fftpack) with scipy, DCT-type-1 / DCT-type-3 is consistent with the behavior of scipy, for DCT-type-2, the result of fftpack is exactly twice as much as scipy's at present. The specific reason is unknown, but it is not caused by this PR.

# python
> from numpy import *
> from scipy.fftpack import *
> dct(array([9,-9,3,0]), 2)
array([ 6.        ,  7.44542921, 21.21320344, 29.06141056])
# Fortran
> print *, dct([real(8)::9,-9,3,0],type=2)
12.0, 14.890858416882008, 42.426406871192853, 58.122821125684993

I'm going to merge it today. If we find any problems, we will be able to make subsequent corrections.

[cval26]

Thank you for taking care of this, @zoziha.

The reason for the factor-of-two difference is that there are several definitions for the DCTs in use, which primarily differ in the selection of the constants. FFTPACK uses a different constant in the definition of DTC-2, compared to SciPy and also FFTW. I think that the choice of FFTW and SciPy is the more natural one and I can argue why, but changing this requires a change in the low-level interface, which should be a different PR subject to further discussion.