Clarity 5 support and `at-block` handling

[hugo-stacks]

Clarinet already pulls a fairly recent version of stacks-core already supports an early version of Clarity 5.

A few more PRs have been merged on stacks-core/develop, so we need to update stacks-core to the latest commit and develop.

About at-block (if the vote passes)

A vote will soon start to decide the fate of at-block in epoch 3.4.
If the vote passes, at-block will be remove and "Any deployed contract that calls at-block will begin receiving runtime errors after Epoch 3.4 activates."

What it means for Clarinet

This logic can remain as it is but the comment need to be adapted. This behavior won't be "fixed" (it won't matter after at-block removel

clarinet/components/clarity-repl/src/repl/datastore.rs

Lines 1261 to 1278 in 8167d2a

	fn get_tip_burn_block_height(&self) -> Option<u32> {
	use StacksEpochId::*;
	match self.current_epoch {
	Epoch10 | Epoch20 | Epoch2_05 | Epoch21 | Epoch22 | Epoch23 | Epoch24 | Epoch25 => {
	let current_chain_tip = self.current_chain_tip.borrow();
	if let Some(height) = self.get_burn_block_height_for_block(&current_chain_tip) {
	return Some(height);
	}
	self.remote_block_info_cache
	.borrow()
	.get(&current_chain_tip)
	.map(|block| block.burn_block_height)
	}
	// preserve the 3.0 -> 3.3 special behavior of burn-block-height
	// https://github.com/stacks-network/stacks-core/pull/5524
	Epoch30 | Epoch31 | Epoch32 | Epoch33 | Epoch34 => Some(self.burn_chain_height),
	}

We want to add a lint so that contracts using at-block get an info message with the following:

A SIP proposes removing the `at-block` function starting in Epoch 3.4. If approved, new contracts using `at-block` will be rejected at deployment. Learn more and vote [here](https://ballot.gg/67a34537-0375-4046-a4b7-432e8dfd4eb3/1MP9LjMBZRKXWq3tRio6nGwFyUoboozEQx).

Todo

• Re-update to latest stacks-core/develop once feat: remove at-block in 3.4 stacks-network/stacks-core#6937 is merged

[linear]

CNET-211