badges for executable-only packages are messed up

[Gankra]

I filed this downstream but as noted in that description, docs.rs isn't really giving shield.io much to work with to handle the issue.

Downstream issue: badges/shields#8440

Either builds.json should set build_status: true (?) for executables, or it should include an extra flag saying "oh this was just an executable, there was nothing to build".

("Why are you even using the shield" -- because it's a common idiom and what a lot of people reflexively reach for when checking for docs, even if it will just link something containing the README again, with just a bit more metadata like flags.)

[syphar]

I don't see any issue exposing this in the builds.json output.
I'm happy to review a PR implementing this change.

Mentoring instructions:

• web::releases::build_list_handler
• add releases.is_library field to the SQL statement & JSON output, the same way as we read & expose releases.rustdoc_status right now.
• adapt the tests accordingly
• no need to show this in the interface.

[calebcartwright]

Just want to add that we'll happily update things on the Shields.io side once this is in place 👍

Actually I misunderstood, thought the response structure was going to be changed, but doesn't sound like that'll be necessary

[Nemo157]

I think we probably do want to change the structure, add a has_library: bool field to it (the naming is_library in the database is subtly wrong since a package can contain both a library and some binaries). We may supporting documenting binaries in the future which would give build_status: true, has_library: false.