[roll] Roll fuchsia [fidl][apidiff] Remove "Transitionable" classification

This CL removes the "Transitionable" classification from fidl_api_diff,
making its conclusion binary: SourceCompatible or APIBreaking.

This term was introduced in RFC-0024 to mean a change "for which it is
possible to write code that compiles before and after the change." In
//src/tests/fidl/source_compatibility/README.md we further classified
such changes as FIDL-assisted or source-assisted (more on this below).
These are useful concepts, but too subtle for automated checks. The API
compatibility checks were testing `conclusion == "APIBreaking"`, so they
would let through breaking changes such as changing strict/flexible.
Those changes will now be rejected.

For more background, here is a taxonomy of transitionable changes and
how to think about them in light of versioning:

* FIDL-assisted: when the intermediate state lives in FIDL, e.g.
  @transitional.

  With FIDL versioning, this is better thought of as two separate
  changes, initial -> intermediate and intermediate -> final. For
  example, we could track @transitional in API summaries, and disallow
  method addition without it. (We aren't doing that for now; see the
  comment added in tools/fidl/lib/apidiff/report.go.)

* Source-assisted: when the intermediate state lives in user code. This
  divides further into two cases:

  * Trivial: when the intermediate state consists of removing all
    references to something. For example, RFC-0024 described table field
    removal as transitionable because it's safe as long as all uses of
    the field are removed.

    With FIDL versioning, the lifecycle of addition, deprecation, and
    removal formalizes this for all elements. (The interesting thing
    about table field removal is that it is *ABI* compatible.)

  * Nontrivial: when the intermediate state is more complicated. For
    example, intermediate code for strict enum -> flexible enum must
    avoid using certain APIs, and it requires language-specific steps
    such as using #[allow(dead_code)] in Rust. These kinds of changes
    are only practical at a small scale where we control all code.

    With FIDL versioning, you should simply make the breaking change at
    a future API level, assuming the burden of adapting to the new API
    is not too great. Otherwise, you should introduce a new element and
    deprecate and remove the old one, rather than changing it in place.

Test: fx test tools/fidl/lib/apidiff
Original-Bug: 107567
Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/721564
Original-Revision: ec38396264393d9ec5e24fd5132cd691f989019c
GitOrigin-RevId: 8d97bcdc79a48d95205dd085238807c779eb39ef
Change-Id: I7a5f8b29bd35c537c1b5c10c143ae104c038860d