Use staged_builder

[sfackler]

Before this PR

We directly codegened staged builder logic, with each stage being a separate type.

Constructors were generated for all types which had 3 or fewer fields, and the constructor required all of them.

After this PR

==COMMIT_MSG==
Object builders are now generated with #[staged_builder]. Constructors now ignore optional fields.
==COMMIT_MSG==

The builders generated by #[staged_builder] are much cleaner in rustdoc output, as all of the setters are rendered on one page: https://docs.rs/staged-builder/latest/staged_builder/example_person/struct.Builder.html

Possible downsides?

The constructor change will be a someone nontrivial source break, but should make wire-compatible evolution of Conjure objects less likely to be a Rust-incompatible change.

Closes #347
Closes #348

[changelog-app]

Generate changelog in changelog/@unreleased

What do the change types mean?

• feature: A new feature of the service.
• improvement: An incremental improvement in the functionality or operation of the service.
• fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.
• break: Has the potential to break consumers of this service's API, inclusive of both Palantir services
  and external consumers of the service's API (e.g. customer-written software or integrations).
• deprecation: Advertises the intention to remove service functionality without any change to the
  operation of the service itself.
• manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration,
  performing database surgery, ...) at the time of upgrade for it to succeed.
• migration: A fully automatic upgrade migration task with no engineer input required.

Note: only one type should be chosen.

How are new versions calculated?

• ❗The break and manual task changelog types will result in a major release!
• 🐛 The fix changelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease.
• ✨ All others will result in a minor version release.

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Object builders are now generated with #[staged_builder]. Constructors now ignore optional fields.

Check the box to generate changelog(s)

• Generate changelog entry

[pierceforte]

Why can it just do into here, whereas the Any type in a map or vec needs a customer serializer like https://github.com/palantir/conjure-rust/pull/349/files#diff-8fcc3688b43688b6b278cb5ba8f57cc9c0446f2b1200d948142255818816227cR11-R17?

[pierceforte]

As an aside, could we just define the custom serializer once somewhere so it doesn't have to keep redefining it? The other conjure_object types only have the #[builder()].

[pierceforte]

I actually think this is specific to the Option, because conjure_object::Any has the custom serializer here https://github.com/palantir/conjure-rust/pull/349/files#diff-450a3ab87b025c7854669c7345e9221165642460bc03581346e2ed08db393726R11-R18

[sfackler]

We can use into for places where we want the conversion logic to just use an Into implementation.

You can see in the deleted manual builder code below that the behavior here matches what we were doing previously.

[pierceforte]

I notice that most of the conjure_object types don't need to specify into here. What makes that possible, whereas the String type does need the into?

[sfackler]

It depends on what conversion behavior we want to support for the setter. With an e.g. i32 we just take that type directly, whereas for string we take impl Into<String> so you can pass in e.g. string literals directly.

[sfackler]

The empty #[builder()] attributes aren't necessary - I pushed up a commit to remove them.