Fix to prevent infinite recursion in __getattr__

[yaelbh]

I'm trying to deep-copy a backend. But then I enter an infinite recursion:

  File "/home/yaelbh/miniconda3/envs/env1/lib/python3.9/copy.py", line 172, in deepcopy
    y = _reconstruct(x, memo, *rv)
  File "/home/yaelbh/miniconda3/envs/env1/lib/python3.9/copy.py", line 271, in _reconstruct
    if hasattr(y, '__setstate__'):
  File "/home/yaelbh/miniconda3/envs/env1/lib/python3.9/site-packages/qiskit_ibm_provider/ibm_backend.py", line 247, in __getattr__
    return self._configuration.__getattribute__(name)
  File "/home/yaelbh/miniconda3/envs/env1/lib/python3.9/site-packages/qiskit_ibm_provider/ibm_backend.py", line 247, in __getattr__
    return self._configuration.__getattribute__(name)
  File "/home/yaelbh/miniconda3/envs/env1/lib/python3.9/site-packages/qiskit_ibm_provider/ibm_backend.py", line 247, in __getattr__
    return self._configuration.__getattribute__(name)
  [Previous line repeated 987 more times]

Printing name at the beginning of __getattr__:

__deepcopy__
__getstate__
__setstate__
_configuration
_configuration
_configuration
_configuration
_configuration
_configuration
_configuration
... and so on

I don't understand why deepcopy reaches __getattr__, and why the recursion occurs. I noticed that the fix suggested in this PR seems to work: the backend's copy is created without exceptions and runs correctly. However, since I don't really understand what's going on, I can't guarantee that the copying worked flawlessly (and that in general adding _configuration to the list does not break anything).

[coveralls]

Pull Request Test Coverage Report for Build 5114036396

• 0 of 1 (0.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 50.232%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit_ibm_provider/ibm_backend.py	0	1	0.0%

Totals
Change from base Build 5082667566:	0.0%
Covered Lines:	3033
Relevant Lines:	6038

---

💛 - Coveralls

[yaelbh]

Closing, I think it's better if a team member who understand the full picture does it. Opened #654 for this purpose.