fix: transformation of unconstrained contract library methods

[nventuro]

We were not discarding contract library methods when searching for top-level unconstrained fns, and so any such function would get the UnconstrainedContext initialization injected, resulting in the correspoding oracle calls being included. If this were to be called from public, the transpiler would fail due to the unknown oracles, resulting in unconstrained contract library methods being unusable in public (and likely in private too, though this would fail at runtime).

I opened #12743 to track the work in formalizing the notion of top-level unconstrained fns (soon to be #[query] or #[app-query] or #[application] or something).

Fixes #12732

[nventuro]

@fcarreiro these functions were being called directly from public functions like any regular noir function, but any fn directly inside the contract mod gets made a contract entrypoint automatically (weird I know). We now detect and warn when we see these, so I added the contract_library_method attribute, which makes the fn not be an entrypoint (weird I know), which I assume is what you originally intended.

[fcarreiro]

Thanks yes! I guess they should be unconstrained as well? In any case if this works we can check later

[nventuro]

No need, they'll be converted to unconstrained automatically if called from an unconstrained fn (like public fns are). We'd only need to make this helper unconstrained if we needed to use any of the unconstrained features (e.g. while or break).