* chore: remove callset from `Procedure`

* chore: fix clippy

* chore: Add warning about `no_std` environment

* specify target triples

* Document all crates with the `no_std` feature

* refactor: wrap MastFores in Program and Library in Arc
* fix: enforce that program entrypoints are procedure roots
* refactor: add external nodes to MastForest for re-exports

This reverts commit 72a7093.

…er-remove-uniqueness

Remove uniqueness invariant from `MastForestBuilder`

…int-fixes

fix(assembly): properly indent first op in nested blocks

This commit modifies the way we handle invalid inputs to u32 operations.
The behavior being modified here is documented as undefined, so is not a
breaking change, and as you will see, should be an improvement in
developer experience.

Previously, virtually all of the u32 operations whose implementations
rely on the operands being valid u32 values, would simply cause the VM
to panic if that assumption was violated in an egregious enough fashion,
namely if the operands happened to be large enough to cause the
equivalent operation on u64 operands to fail.

While somewhat limited in impact in practice, this is quite painful if
you have a bug in your program that causes a very large value to be used
as an operand to a u32 operation. Not only would this bring the entire
VM down, it would also prevent you from identifying _why_ it failed,
even if stepping cycle-by-cycle. This primarily impacts the arithmetic
operators, but really just depends on how a given instruction is
implemented.

More problematic, in my opinion, is that while the behavior of the u32
operations with invalid u32 operands is documented as undefined, we were
relying on the undocumented behavior of the VM in various places,
notably in the implementations of some of the more complex bitwise
operations, e.g. clz/clo/rotr. As a result, if we were to ever change
that undocumented behavior, subtle bugs could be introduced. In this
case, we're making the behavior more strict, so we're immediately made
aware that these operations are broken (and thus, fix them), but we
could have easily done something different that would not have been so
easy to detect.

This commit specifically makes most of the u32 ops raise an execution
error if an invalid u32 operand is given to them. This does _not_ make
these checked operations in terms of the VM constraints, but it does
make them behave like checked operations, in so far as they will cause
the VM to trap if an invalid operand is used. This stricter behavior
makes you aware immediately when your program relies on undefined
behavior, and forces you to handle it properly.

* feat: move decorators to `MastForest`

* `DecoratorList` uses `DecoratorId`

* feat: add `before_enter` and `after_exit` decorators to MAST nodes

* WIP: `MastForestBuilder::make_basic_block()` returns `Either<Option<MastNodeId>, Vec<DecoratorId>>`

Still WIP on fixing `compile_body()` - specifically handling what to do when `make_basic_block()` returns a list of decorators

* fix build

* fix build after merge

* fix repeat statement

* implement `before_enter` and `after_exit`

* changelog

* fix no_std

* print decorators in BasicBlockNode

* join node pretty print

* basic block and repeat tests

* join decorators test

* implement pretty print for all nodes

* call node pretty print

* dyn node pretty print

* decorators external node

* join and split node pretty print

* fix `eq_hash`, and test `decorators_repeat_split`

* `MastForestBuilder`: add_decorator -> ensure_decorator

* fix asmop hash

* fix docs

* fmt

* add failing test

* eq_hash: now takes into account children's eq hashes

* remove redundant comment

* fix `MastForestBuilder::ensure_node` docs

* expand on `add_library` comment

* Remove `Either` type

* `add_block_with_raw_decorators` clarifying comment

* Move `&mut MastForestBuilder` into `BasicBlockBuilder`

* split `add_library()` docstring into 3 paragraphs

* Fix `MastForest` serialization (#1482)

* Move strings data to its own buffer

* move StringTableBuilder out of BasicBlockDataBuilder

* Create `StringTable` type

* Encode decorators separately

* fix strings table

* Introduce Operation iterator in BasicBlockNode

* Document use of `MAX_DECORATORS` value

* fix typo

* merge `basic_block_data_decoder` and `basic_block_data_builder` modules

* Use `DecoratorId::from_u32_safe` in deserialization

* serialization failing test

* serialize before_enter/after_exit maps

* Document serialization format

* rename `BasicBlockNode::operation_iter`

* `MastNodeInfo::new()`: soft enforce 0 values for non-basic block nodes

* update docstring for `BasicBlockDataDecoder`

* decorator id deserializing meaningful errors

* move `basic_block_data_decoder` var

* Don't use maps for before enter/after exit decorators

* block_builder var name

* Introduce new `EqHash`

* Cleanup `BasicBlockBuilder::make_block()`

* Incorporate assert and mpverify arguments into eq_hash

* update code organization docs

* chore: simplify `batch_ops`

* update comment

* docs: fix decoder constraints

* add clarification

* fix constraints

Introduce `Emit` instruction

* fix(docs): Fix number of locals and typos

* fix(docs): Consistently use `advstack` for the advice stack

This commit introduces the concept of attributes/annotations to Miden
Assembly procedures. These can be used to represent interesting/useful
bits of metadata associated with specific procedures in three different
forms:

* Marker attributes, e.g. `@inline`, a name with no associated data
* List attributes, e.g. `@inline(always)`, i.e. a parameterized
  marker; multiple values can be provided as comma-delimited metadata
  expressions.
* Key-value attributes, e.g. `@props(<key> = <value>, ...)`, where
  `<key>` must be a valid identifier, and `<value>` must be a valid
  metadata expression. Multiple key-value attributes can be set at once,
  or you can specify the same key-value attribute multiple times, so
  long as each instance does not have any keys that conflict with
  previous instances.

Metadata expressions come in three possible types:

* bare identifier, e.g. `foo`
* quoted string, e.g. `"some text"`
* integer value, either decimal or hexadecimal format, e.g. `1` or
  `0x01`

Attributes will provide the foundation for upcoming changes that will
rely on being able to attach metadata to procedures. For now, attributes
may _only_ be attached to procedure definitions, not re-exports or any
other syntactic construct.

NOTE: This does not yet act on any attributes, nor store them anywhere
when assembling to MAST. For now, they are simply parsed, made available
in the AST, and ignored. Future PRs will introduce these as needed.

Closes #1434

…-vtable

Fix chiplets vtable construction

feat: implement procedure annotation syntax

…able-respan

Fix block stack table respan

docs: Document how `CALL` and `SYSCALL` work, and fix block stack table

Co-authored-by: Andrey Khmuro <[email protected]>