Add BlockApi trait.

[azteca1998]

Solves #634 by moving the Block's API into a separate trait.

The same principle can probably be applied also to RegionRef and OperationRef.

[edg-l]

Looks good to me, it duplicates a bit of code but I don't know another way that isn't a big rewrite, what do you think @raviqqe ?

[azteca1998]

The alternative would be to duplicate the methods manually, but doing it this way allows us to have functions that accept both Block and BlockRefs by declaring the argument as block: impl BlockApi.

[raviqqe]

Thank you for the changes! I'm gonna take a look soon.

[raviqqe]

Is this typing correct although blocks can be dangling? We don't need to append blocks to regions first to modify blocks in the current API.

Looking at the types and lifetimes of the implemented methods, you meant for 'v to be the lifetime of Block's themselves?

For example, currently the following test passes:

    #[test]
    fn static_argument() {
        let context = create_test_context();
        context.set_allow_unregistered_dialects(true);
        let block = Block::new(&[(
            IntegerType::new(&context, 64).into(),
            Location::unknown(&context),
        )]);
        let _arg: BlockArgument<'_, 'static> = block.argument(0).unwrap();
    }

[azteca1998]

I'm not sure, but it seems you've figured it out already.
Your way is probably better since you're binding the 'v lifetime to Self.

[raviqqe]

@edg-l @azteca1998 It doesn't have to be addressed here. But FYI, we should technically have BlockRefMut in the future although we use BlockRef for both immutable and mutable references now. 😅

[raviqqe]

Ah, sorry I somehow force pushed to your branch!

[raviqqe]

@azteca1998 @edg-l Can you take a look at this? azteca1998#1

[azteca1998]

Ah, sorry I somehow force pushed to your branch!

No problem.

Can you take a look at this? azteca1998#1

Merged.