Add UNKNOWN values to blimp proto enums

blimp/common/proto/blimp_message.proto

Index: blimp/common/proto/blimp_message.proto
diff --git a/blimp/common/proto/blimp_message.proto b/blimp/common/proto/blimp_message.proto
index e81c608f09633d6128cb752d01ea213d6f93863d..9b1168419a7267296fb003a0e4bf531d1e483ea2 100644
--- a/blimp/common/proto/blimp_message.proto
+++ b/blimp/common/proto/blimp_message.proto
@@ -33,10 +33,11 @@ package blimp;
 
 message BlimpMessage {
   enum Type {
-    COMPOSITOR = 0;
-    INPUT = 1;
-    CONTROL = 2;
-    NAVIGATION = 3;
+    UNKNOWN = 0;

[maniscalco, 2015/11/20 22:33:48]

Breaking the cardinal rule here, but I believe it's OK because there is nothing
"in the wild" for us to break.  Of course if we have serialized protos stashed
away somewhere (files for replay, databases, etc.).  We'd need to update those
as well.

[Wez, 2015/11/20 23:33:39]

Agreed; we are OK w/ breaking changes to the protocol at least until we reach
the v0.5 milestone, FWIW.

nit: Is UNKNOWN the convention, or INVALID?  Fundamentally, via versioning, a
peer sending out-of-range values is misbehaving, so I'd treat that as invalid
input.

[maniscalco, 2015/11/20 23:42:21]

The convention I'm familiar with is to use UNKNOWN or FOO_UNKNOWN where FOO is
the name of the enum.

I understand what you mean about it being invalid in our use.  My instinct is to
stick with UNKNOWN since it's more common, but I'm happy to change it if you
feel strongly.

+    COMPOSITOR = 1;
+    INPUT = 2;
+    CONTROL = 3;
+    NAVIGATION = 4;
   }
   // Identifies the feature type of this message.
   // The feature-specific contents are contained in optional fields of the same