Adopt C#/Rust-style unsafe contexts

[densh]

Unsafe (pointers, stack allocation, extern calls and friends) features can only be used in unsafe context:

• @unsafe methods
• unsafe { ... } blocks

This clearly demarcates usage of unsafe features, making it impossible to use them by accident.

[rightfold]

Do calls to @unsafe methods count as unsafe, like in Rust (and unlike in C#, where unsafe is always lexical)?

[densh]

Yes, they do count as unsafe.

[rightfold]

Yay!

[gurinderu]

@densh Could you add an ability to use IR code in this task or maybe in separate?

For example

def start: Unit ={
 ir{
  %src.2 = alloca %"scala.scalanative.runtime.OmrThread"
  %src.3 = bitcast %"scala.scalanative.runtime.OmrThread"* %src.2 to i8*
  %src.4 = alloca void(...)*, align 8
  store void (...)* bitcast (void (i8*)* @"java.lang.Thread::run_unit" to void (...)*), void (...)** %src.4, align 8
  %src.5 = load void (...)*, void (...)** %src.4, align 8
  %src.6 = bitcast void (...)* %src.5 to i8*
  call void (i8*, i8*, i32, i8*, i8*) @"omrthread_create_ex"(i8* %src.3, i8* zeroinitializer, i32 0, i8* %src.6, i8* zeroinitializer)
 }
}

Also, it would be perfect to add annotation which marks method us usable in IR and does not remove them in dead code elimination phase

[densh]

@gurinderu Including inline IR in the code is not something that we are going to support. IR is subject to change without further notice, it's not meant to be stable. We want to have freedom to innovate in this area without breaking end-users code.

Regarding the second feature suggestion, I do not quite get exactly what you mean. Lets discuss on gitter. Also please try to refrain from suggesting new features in issues which are not strictly related to your suggestion (like this one.)