Fixing docstrings & indentation related warnings for Sphinx

[DhruvSondhi]

This PR aims to fix all the warnings related to the docstring & indentations that are being generated when building the documentation.
Docstrings have been updated successfully.
Most of the indentation errors have been fixed.

Documentation Preview: https://dhruvsondhi.github.io/tardis/branch/fix_docstring_errors/index.html

Description

Some of the docstring had unexpected indentations & hence rose warnings whenever building the documentation
A notable example can be seen here:
before --> Check here
after --> Check here

Some of the documentation pages had wrong directives for code blocks. Those have been taken care of in the Pull Request.
This removes these warnings & hence makes it easier to build the documentation

Motivation and context

Fixing Sphinx Warning will allow for better generation of the Documentation via Sphinx.

How has this been tested?

• Testing pipeline.
• Other. Created the documentation on my fork

Type of change

• Bug fix.
• New feature.
• Breaking change.
• None of the above.

Checklist

• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • (optional) I have built the documentation on my fork following the instructions.
• I have assigned and requested two reviewers for this pull request.

[github-actions]

Before a PR is accepted, it must meet the following criteria:

• Is the necessary information provided?
  • Does the PR have a complete description? Does it explain what the PR is attempting to do/fix, does it explain how it does this?
  • Is there an explanation of why this PR is needed?
  • Please use the TARDIS PR template
• Is this a duplicate PR?
  • If a new PR is clearly a duplicate, ask how this PR is different from the original PR?
  • If this PR is about to be merged, close the original PR with a link to this new PR that solved the issue.
• Does it pass existing tests and are new tests provided if required?
  • The test coverage should not decrease, and for new features should be at or very close to 100%.
• Is the code properly documented?
  • If this modifies existing code, then the docs should be updated. If this adds a new feature, additional documentation should be created.
  • Sphinx and docstrings in the code (in numpydoc format)
• Does this conform to PEP 8 and the TARDIS style guidelines?
• Does the PR fix the problem it describes?
  • Make sure it doesn’t e.g. just fix the problem for a specific case
  • Is this the best way of fixing the problem?
• Is the code tidy?
  • No unnecessary print lines or code comments

[codecov]

Codecov Report

Merging #1617 (2ee1996) into master (e062c69) will not change coverage.
The diff coverage is n/a.

❗ Current head 2ee1996 differs from pull request most recent head aa59a8c. Consider uploading reports for the commit aa59a8c to get more accurate results

@@           Coverage Diff           @@
##           master    #1617   +/-   ##
=======================================
  Coverage   67.20%   67.20%           
=======================================
  Files          73       73           
  Lines        6150     6150           
=======================================
  Hits         4133     4133           
  Misses       2017     2017           

Impacted Files	Coverage Δ
tardis/tardis/io/atom_data/base.py	90.80% <0.00%> (ø)
tardis/tardis/montecarlo/packet_source.py	97.29% <0.00%> (ø)
tardis/tardis/plasma/properties/atomic.py	61.76% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 802fab9...aa59a8c. Read the comment docs.

[isaacgsmith]

How should we rewrite this now that we do not use OpenMP @andrewfullard

[andrewfullard]

Out of scope for this pull request. However, it should be changed. The note for that variable should be removed, assuming it is still used in the class.

[tardis-bot]

Before a pull request is accepted, it must meet the following criteria:

• Is the necessary information provided?
• Is this a duplicate PR?
  • If a new PR is clearly a duplicate, ask how this PR is different from the original PR?
  • If this PR is about to be merged, close the original PR with a link to this new PR that solved the issue.
• Does it pass existing tests and are new tests provided if required?
  • The test coverage should not decrease, and for new features should be close to 100%.
• Is the code tidy?
  • No unnecessary print lines or code comments.