[BUG] Wrong converting back from Bookie entry to AMQP Message

Start with the README's simple py-amqp producer/consumer example and reproduce the reported values for timelimit and retries. Trace the Bookie-entry-to-AMQP-message conversion and verify that the consumer preserves the producer's AMQP field types, including the array and numeric values.

Describe the bug
We are using Celery which is based on https://github.com/celery/py-amqp/ to communicate well with RabbitMQ. The producer push a message with property application_headers and the AoP received it properly, but when the consumer receive that message, the application_headers does not retain field value type of AMQP (the application_headers is a Table).

To be more precise. this is what I received if using RabbitMQ:
{'lang': 'py', 'task': 'inbox.tasks.send_customer_feedback', 'id': 'c6d4aa27-eb05-430a-b7dd-1d99c4068a3f', 'shadow': None, 'eta': None, 'expires': None, 'group': None, 'retries': 0, 'timelimit': [None, None], 'root_id': 'c6d4aa27-eb05-430a-b7dd-1d99c4068a3f', 'parent_id': None, 'argsrepr': '(1,)', 'kwargsrepr': '{}', 'origin': 'gen11955@s1.docker'}
The application_headers above and it's field types is recognized very well.

But this is what I received when using AoP:
{'retries': '0', 'task': 'inbox.tasks.send_customer_feedback', 'origin': 'gen14354@s1.docker', 'argsrepr': '(1,)', 'kwargsrepr': '{}', 'root_id': '1fffa52f-3c68-47e8-b3bc-1c7135f7a913', 'id': '1fffa52f-3c68-47e8-b3bc-1c7135f7a913', 'lang': 'py', 'timelimit': '[null, null]'}
All of the items of application_headers was strings. Please look at the timelimit attribute for easier comparison and you will see that it's sent as array of None (null in Python) but now it's received as a string of may be json serialized. Additionally, the retries should be a number but now it's string. That causes the application can not properly parse the application_headers entries.

To Reproduce
Steps to reproduce the behavior:

1. Use py-amqp to produce a message (there is a simple example in the README)
2. Consume back the message produced above
3. The timelimit attribute (and some others) do not retain it's type.

Expected behavior
The timelimit is responded with proper AMQP message type or retain the type from producer.

Additional context
I'm using py-amqp 2.6.1 and AoP 2.8.1.13

Many thanks for this great project.