Add pyfftw sdp

[NimaSarajpoor]

This is to address PR 3 described in #1118 (comment). Have copied the corresponding notes below:

1. Add _PYFFTW_SLIDING_DOT_PRODUCT to sdp.py
2. Add unit tests that demonstrate that _PYFFTW_SLIDING_DOT_PRODUCT matches the results of naive_rolling_window_dot_product
3. Handle the test.sh check_fftw_pyfftw stuff here too

[gitnotebooks]

Review these changes at https://app.gitnotebooks.com/stumpy-dev/stumpy/pull/1132

[seanlaw]

@NimaSarajpoor I've left some comments for you to address. I think we can afford to be clearer since all of this pyfftw stuff will be hard to maintain. We should probably be as verbose (and add more comments cross referencing their docs as possible). I'll do another few passes after you've responded and made modifications. I think this pyfftw stuff needs to be crystal clear

[NimaSarajpoor]

@seanlaw
This PR should be ready to be merged if there are no concerns.

[NimaSarajpoor]

Maybe add a comment here that says: "The name of any callable object that computes the sliding dot product should end with sliding_dot_product"

[NimaSarajpoor]

Suggested change

	# with multiple threads and longdouble data type
	# longdouble data type, and then called in a multithreaded mode.

Note that the number of threads is not set when the instance is created

[NimaSarajpoor]

Suggested change

	# This test checks that the pyfftw_sdp can be initialized
	# This test checks that the pyfftw_sdp instantiated object
	can be called in a multithreaded mode.

[NimaSarajpoor]

Suggested change

# with multiple threads

[NimaSarajpoor]

Suggested change

	max_n : int, default=2**20
	max_n : int, default 2**20

[NimaSarajpoor]

Suggested change

	real_dtype : str, default="float64"
	real_dtype : str, default "float64"

[seanlaw]

@NimaSarajpoor This might be a distraction but a (very, very small) part of me was wondering if we should be using a closure instead of a class:

https://realpython.com/python-closure/

I don't know if it makes things easier/harder to read. Given all of the array allocations, maybe a class is the right thing to use. I just wanted to bring it to your attention since I'm not sure we're getting the full benefits of a class since:

1. None of the class attributes are actually being accessed externally
2. We don't really have an external method (except __call__) but we do want to make it a function

Just something to consider. No pressure though.

[NimaSarajpoor]

We don't really have an external method (except call) but we do want to make it a function

This is something that bothered me too but thought the reason for being bothered is just my lack of experience and, also, I didn't know/think about an alternative option.

but a (very, very small) part of me was wondering if we should be using a closure instead of a class:
https://realpython.com/python-closure/

Thanks for sharing this! I will go through this and try to modify the script. Let's see how it will look like.