nrf51288-DK BLE peripheral security

Hi @Gordon, I think I found a better option that would be useful for all nrf boards. Just wanted to validate something with you before I create a PR.

It just turned out that it is a bit problematic to add that event. Well, it is not difficult for the peripheral mode, but quite problematic for the central mode as you need to figure out MAC address by using handle ID, so that we can pass it as a parameter to the event.

Anyway, there is what I think is a better option. When characteristics get added/configured, espruino marks them as "open to read/write" here.

Instead of making them wide open, we could come up with something like that:

        if (jsvGetBoolAndUnLock(jsvObjectGetChild(charVar, "encrypted", 0))) {
            BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.read_perm);
            BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.write_perm);
        } else {
            BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm);
            BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);
        }

So that users can configure characteristics in JS like that (forcing encryption):

NRF.setServices({
  0xBCDE : {
    0xABCD : {
      value : "Hello", 
      readable: true,
      writable : true,
      encrypted: true,
      onWrite : function(evt) {
         print("Written: " + evt.data);
      }
    }
  }
});

I've tested this, it is kind of working, in a bit an unexpected way though. I'd have thought if you configure a characteristic to be encrypted, then if the link is not encrypted it should fail, but instead it looks like bonding happening automatically. Well, it works differently for different environments:

1. Both Bluez and android encrypt characteristics automatically, ie. without initiating bonding procedure manually.
   
2. Bluegiga serial BT adapter fails to read/write, ie. it does not encrypt characteristics automatically.
   
   

I'll need to do more tests with a BT sniffer to make sure it actually encrypts, will do this over this weekend.

Now just wanted to validate the config format. Some users may want to configure read and write encryption separately, e.g. encrypt it only for write and let read operation open. Furthermore, some user may want to use different security levels, e.g. "man in the middle" or even "signed". I'm thinking to let users configure the security in this format:

NRF.setServices({
  0xBCDE : {
    0xABCD : {
      value : "Hello", 
      readable: true,
      writable : true,
      security: {
        read: "open", // default
        write: "encrypted" // could be also: "encrypted_signed", "mitm", "mitm_signed", "lesc_mitm"
      },
      onWrite : function(evt) {
         print("Written: " + evt.data);
      }
    }
  }
});

All those security constants correspond to these macros

Please let me know what you think.