Add TargetFile.custom() documentation when building readthedocs

[MVrachev]

Fixes #1602

Description of the changes being introduced by the pull request:

Add the missing Targetfile.custom() property to the RTD documentation.
This property is not documented and is not visible in RTD documentation:
I think it would be useful to expose as the "supported" way for a client app to read custom metadata for a target.

Please verify and check that the pull request fulfills the following
requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[coveralls]

Pull Request Test Coverage Report for Build 1663921369

• 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 97.737%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
tuf/api/metadata.py	0	1	0.0%

Totals
Change from base Build 1658257798:	0.0%
Covered Lines:	4092
Relevant Lines:	4171

---

💛 - Coveralls

[MVrachev]

I managed to add the TargetFile.custom() property in the RTD documentation.
Now I want to research how can I add information about the custom type: Dict[str, Any] by using the sphinx format.

[MVrachev]

I realized I was mistaken about the custom property, it's both documented and type annotated.
The only question remaining is are we sure the custom type is Any or it's actually Dict[str, Any]?
@jku what do you think?

[MVrachev]

By adding a docstring to the property RTD noticed custom and documented it.

[jku]

The only question remaining is are we sure the custom type is Any or it's actually Dict[str, Any]?

I wouldn't object to either.

Specification (summarized by me):

CUSTOM: An object.

Object is never defined but does seem to mean JSON object -- a dictionary with string keys -- so annotating it as such seems reasonable. There's probably no need for us to validate custom in deserialization though.

[ivanayov]

@jku A valid json in python works for boolean and number strings as well, so in that case Dict might not fit. On the other hand it would be a bit strange to attach such non-informative value to TargetFile, unless someone decides to use if for a hacky implementation in a very specific corner-case. But should we still allow that or just consider it's useless and restrict to Dict? With the change it nicer to use, formally it's not Any anymore.

[MVrachev]

@jku A valid json in python works for boolean and number strings as well, so in that case Dict might not fit. On the other hand it would be a bit strange to attach such non-informative value to TargetFile, unless someone decides to use if for a hacky implementation in a very specific corner-case. But should we still allow that or just consider it's useless and restrict to Dict? With the change it nicer to use, formally it's not Any anymore.

You are correct that custom could be a List and boolean, string and an int as well.
We are not sure what it could be in this case even though Dict makes the most sense.
I removed the commit that changes the type annotation.