`port c++ framer op to open source in tflm_signal`
-port framer op and corresponding to new open source location for C++
BUG=[b/288965505](https://b.corp.google.com/288965505)
This is needed to properly build all the ops together. Since we are calling into a singular utils function to load the ops, if it checks for any other ops, it would break before this.
Now we make it build all ops everytime utils.py is built.
BUG=[288938993](http://b/288938993)
Second OP for the TFLM Signal library, Real-Valued Fast Fourier Transform.
The RFFT OP provides three resolutions: `FLOAT, INT16, INT32`
Similar usage as to previous Window OP:
* `op_resolver.AddRfft()` (which will add all resolutions, and determine the type at runtime)
* `op_resolver.AddRfftFloat()`, `op_resolver.AddRfftInt16()`, `op_resolver.AddRfftInt32()` for a specific resolution type.
* or via python as can be seen in `fft_ops_test.py`
3 testing options are provided:
* Micro(C++): bazel run signal/micro/kernels:fft_test
* Tensorflow/Micro(Python): bazel run python/tflite_micro/signal:fft_ops_test
* Makefile(C++): make -f tensorflow/lite/micro/tools/make/Makefile test_kernel_fft_test
BUG=[287346710](http://b/287346710)
To package the module `runtime` as `tflite_micro.runtime`, put `runtime` under
a directory representing the Python namespace package `tflite_micro`. For
organization's sake, move it all to the top-level directory `python/`. Adjust
tests and docs to match.
Some code outside of the Python extension module has come to depend on
`python/tflite_micro:python_ops_resolver` as a replacement for
`all_ops_resolver` (e.g.:`t/l/m/integration_tests/seanet/add/integration_tests.cc`).
`python_ops_resolver` is intended to be a private implementation detail of the
Python extension module. For now, grandfather in the dependent code by updating
its references to the resolver's location; however, soon the dependent code
should be migrated away to a different resolver. (#2033,
https://issuetracker.google.com/286508251)
BUG=part of #1484
We have some name clash issues with the current Window OP name.
We will be changing it from "Window"->"SignalWindow" until the names clashes are resolved and revert back afterwards.
This is an internal implementation detail, so user level API has no change from current usage, i.e. still use (op_resolver.AddWindow() and window_op.window)
BUG=[286250473](http://b/286250473)
First Op for the TFLM Signal Processing Ops library.
Doc linked in bug.
The Window OP is a custom signal processing OP similar to what is found in tf.signal library, but specific for integer (int16) purposes.
You can directly use this as a builtin op via the op resolver as:
* `op_resolver.AddWindow()`
* or via python as shown in `window_op_test.py`
3 testing options are provided:
* Micro(C++): `bazel run signal/micro/kernels:window_test`
* Tensorflow/Micro(Python): `bazel run python/tflite_micro/signal:window_op_test`
* Makefile(C++): `make -f tensorflow/lite/micro/tools/make/Makefile test_kernel_window_test`
BUG=[259145369](http://b/259145369)
